Что такое модальный диалог

itoa(result,res,10);//Преобразуем результат в строку

strcat(szText,res);//Дополним строку вывода

SetDlgItemText(hwnd,ID_1,szText);//Выведем в диалог

return TRUE;

void DlgOnCommand(HWND hwnd,int id,HWND,UINT)<

case ID_OK: case IDCANCEL:

EndDialog(hwnd,0);//Закроем диалог

В файле ресурсов описываются вид и состав диалогового окна. В нем, кроме заголовка, имеются только два элемента управления – статический элемент управления (класс STATIC, стильSSLEFT) и нажимаемая кнопка (классBUTTON, стильBSPUSHBUTTON). Обоим элементам присвоены идентификаторы (ID1 иIDOK).

Сама программа чрезвычайно проста. Поскольку в ней нет главного окна, то отсутствуют и все программные элементы, с ним связанные: действия по регистрации класса окна, его созданию и показу, оконная функция, функции обработки сообщений для главного окна. В функции Windows теперь только выполняются заданные вычисления (в нашем примере – в цикле суммируются 1000 чисел), после чего вызывается функция DialogBox(), создающая диалоговое окно. Впараметрах этой функции указывается дескриптор приложенияhInst, который берется из параметров функцииWinMain(),имя диалогового окна, данное диалогу в файле ресурсов,NULL в качестве дескриптора окна-владельца (окном-владельцем в данном случае является рабочий стол Windows, а его дескриптор равенNULL) и, наконец, имя оконной функции диалогового окна.

Оконная функция диалога в нашем примере обрабатывает всего два сообщения: WMINITDIALOG иWMCOMMAND. Обработка второго сообщения позволяет реагировать на нажатие кнопоки. Первое же сообщение, об инициализации диалогового окна, как раз и используется для вывода в статический элемент управления результата вычислений. В функцииDlgOnInitDialog()числовой результат, находящийся в глобальной переменнойresult, преобразуется с помощью функцииitoa() в символьную форму, и полученная строка сцепляется со строкой комментария«Сумма чисел = «. Далее посредством функцииSetDlgItem­Text() эта результирующая строка (szText) заносится в элемент управления с идентификаторомID_1.

Таким образом, отличительной чертой этого приложения является динамическое заполнение диалогового окна получаемыми в программе результатами. В нашем примере после закрытия диалога программа немедленно завершается предложением return 0, однако в ней вполне возможно предусмотреть дальнейшие вычисления с повторным созданием диалогового окна, в которое теперь будут помещены новые результаты. Из-за того, что вмодальноедиалоговое окно нельзя передать результаты непосредственно из программы (поскольку программа, как уже отмечалось, блокируется на время существования модального диалога), придется воспользоваться переменной-переклю­чателем, примерно так, как это сделано в примере 3-1, только строки установки значения переключателя следует поместить в главную функцию, а строки анализа его значения – в функциюDlg­On­InitDialog().

Модальные окна, которые понравятся каждому

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

Это – крайние точки на линейке, которой измеряется наши взаимоотношения с пользователем сайта. В зависимости от привычек, личных предпочтений и способа сёрфинга по сети модальные окна могут быть для пользователя благословением или проклятием.

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

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

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

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

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

Семантика кода способствует доступности сайта

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

Чтобы добиться этого, мы должны внимательно отнестись к семантике разметки. Это требование кажется простым, но, к сожалению, оно часто не выполняется. Представьте себе следующий код окна с кнопкой « Закрыть »:

Элемент <div> не имеет определённого смыслового значения в этом контексте. Конечно, его можно опознать как кнопку закрытия окна по визуальным признакам: символу « X » и изменению формы курсора. Но что, если с сайтом работает плохо видящий или незрячий человек?

Чтобы можно было переместить фокус ввода на данный <div>, мы должны использовать атрибут tabindex . Кроме того, состояние, описываемое псевдо-селектором :focus , позволит идентифицировать его как активный элемент. Это сделает управление сайтом при помощи альтернативных устройств возможным, но не слишком простым.

Допустим, что многие пользователи устройств чтения экрана уже знают о том, что буква « X » означает « Закрыть ». Но если мы заменим эту букву на знак умножения (амперсанд-код ×) или крест (❌) ради визуального эффекта, содержимое нашего блока не будет прочитано.

Лучшим решением в данной ситуации будет использовать тэг <button> для обозначения активного элемента, а также добавить в разметку свойство aria-label , специально предназначенное для устройств чтения экрана:

Заменив <div> на <button>, мы значительно улучшили семантику нашего элемента управления. Теперь кнопка ведёт себя полностью предсказуемо: на неё можно переместить фокус при помощи клавиши табуляции, и контекст её использования теперь понятен всем.

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

Делаем модальные окна удобными и доступными

Семантическая разметка поможет нам сделать наше модальное окно более удобным и доступным. А правильное использование стилей и скриптов поднимет юзабилити нашего сайта на новый уровень!

Добавление состояния :focus

Используйте состояние :focus в ваших стилях. Это улучшит не только модальные окна, но и всё управление сайтом. Часто состояние :focus , используемое браузером по умолчанию, переписывается css-reset -стилями, или само по себе недостаточно выделяет активные элементы, или не вписывается в общее оформление сайта.

Допустим вариант, когда вы объединяете состояния :focus и :hover :

Хотя, получение фокуса с клавиатуры и наведение указателя мыши – это всё же два различных состояния, и разумно будет дать им собственные, отличные от других стили:

Каждый элемент, способный получить фокус, должен быть стилизован таким образом. В крайнем случае, если вы не хотите использовать свой стиль :focus , позаботьтесь о том, чтобы сохранить дефолтный стиль браузера – обычно это пунктирное подчёркивание или рамка вокруг активного элемента, имеющего фокус.

Сохранение последнего активного элемента

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

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

Перемещение фокуса

При появлении модального окна фокус должен переместиться на него или на первый интерактивный элемент в нём. Тогда пользователю не придётся браться за мышь или перебирать клавишей “ Tab ” десятки полей и кнопок:

На полный экран

Если ваше модальное окно занимает весь экран, позаботьтесь о том, чтобы элементы управления в основном окне стали на время недоступны. Иначе любой пользователь может продолжить вводить что-то в основное окно, думая при этом, что взаимодействует с модальным. Обеспечить желаемое может скрипт, подобный этому:

Закрывая для пользователя основной экран, мы всё же должны обеспечить для него доступ к элементам управления браузером при помощи всё той же кнопки “ Tab ”. Такого поведения от нашего окна ожидают и обычные, зрячие пользователи.

Вышеприведённый скрипт предотвращает переход фокуса в основной документ, вместо этого перемещая его обратно к первому элементу модального окна.

Если мы заодно поместим модальное окно в вершину дерева DOM , сделав его первым потомком <body>, то комбинация “ Shift”+“Tab ” позволит пользователю переключить фокус на элементы управления браузером:

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

Для этого необходимо сохранять в скрипте их идентификаторы. Когда пользователь нажмёт “Tab” в последнем элементе окна, вы переместите фокус на первый элемент. Нажатие “ Shift”+“Tab ” должно обрабатываться зеркально.

Есть и другие варианты обработки перемещения фокуса. Например, вы можете переназначать и использовать в скрипте списки элементов ввода, между которыми разрешён переход фокуса. Или устанавливать tabindex=-1 на скрываемые активные элементы.

Первый и второй методы делают меню и кнопки браузера недоступными при управлении с клавиатуры. При этом походе критичны хорошо заметный элемент закрытия окна и перехват нажатия клавиши “ Esc ” с той же целью. Иначе ваш сайт станет ловушкой для пользователей без мыши.

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

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

Закрытие

Модальное окно должно легко закрываться. Стандартные диалоги, вызываемые из JavaScript функцией alert() , могут быть закрыты нажатием клавиши “ Esc ”. Будет хорошим тоном придерживаться этого соглашения при создании собственных диалогов.

Если диалог содержит много активных элементов, то гораздо лучше будет дать пользователю возможность закрыть его нажатием одной клавиши, нежели заставлять его пробегать по всем полям, чтобы добраться до кнопки « Закрыть »:

Кроме того, многие разработчики позволяют пользователям закрывать окно щелчком на его свободной области. Для этого можно использовать простой скрипт:

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

Дополнительные меры по обеспечению доступности сайта

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

ARIA-HIDDEN

Устанавливая атрибуту aria-hidden значение true , вы можете скрывать содержимое элемента со всеми его дочерними элементами от программ, читающих экран. Необходимо учесть, что ARIA -элементы не обладают дефолтной стилизацией в браузерах. Чтобы скрыть их от зрячих пользователей, воспользуйтесь следующим CSS -кодом:

Обратите внимание на весьма специфичный селектор. В общем случае мы не хотим прятать абсолютно все элементы с aria-hidden=true. Вспомните предыдущий пример с кнопкой « X », чтобы понять, что имеется в виду.

ROLE=»DIALOG»

Добавьте свойство role=»dialog» ко всем элементам, содержащим модальный контент. Это укажет так называемым техническим средствам реабилитации, что данный контент требует реакции пользователя. Описанные нами скрипты, зацикливающие перемещение фокуса ввода между допустимыми активными элементами, отлично дополнят эту разметку.

Для оповещений, требующих от пользователя простого подтверждения, используйте role=»alertdialog» совместно с теми же скриптами.

ARIA-LABEL

Свойства aria-label и aria-labelledby используются совместно с role=»dialog» . Если ваше модальное окно имеет заголовок, укажите его идентификатор, например: aria-labelledby=modal_header_id . В противном случае задайте описание диалога в качестве значения свойства aria-label .

Как насчёт HTML5-диалогов?

На момент написания статьи Google Chrome версии 37 и ночные сборки Firefox уже научились поддерживать семантический элемент dialog .

Когда данный элемент станет общеупотребительным, это избавит нас от необходимости проставлять role=dialog в различных элементах. Пока же мы рекомендуем использовать role даже при наличии polyfill -библиотек для обеспечения поддержки устройств чтения экрана.

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

Например, чтобы показать или спрятать диалог, мы обычно используем такой скрипт:

Метод show() показывает диалог, вместе с тем оставляя пользователю доступ к остальному сайту. Метод showModal() запускает диалог и запрещает пользователю взаимодействовать с другими элементами сайта.

Элемент dialog имеет свойство open , содержащее true либо false и заменяющее aria-hidden . Псевдо-элемент :backdrop позволит нам использовать особый стиль окна, когда оно запущено при помощи showModal() .

Элемент dialog имеет и другие полезные свойства. Хоть он и не готов пока для использования в массовой разработке, в недалёком будущем он может здорово упростить создание современных, доступных сайтов.

Что дальше?

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

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

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

Сергей Бензенко автор-переводчик статьи « Making Modal Windows Better For Everyone »

Модальные окна: проблемы доступности

Модальные диалоговые окна — все еще один из самых проблемных компонентов пользовательского интерфейса. Отбросим тот факт, что сайты часто ими злоупотребляют, прерывая текущие действия пользователей (просить меня подписаться на вашу рассылку, пока я еще не дочитал статью, совсем не круто). Но даже правильно используемые модальные окна часто не учитывают требования доступности.

На данный момент существует очень много готовых решений диалоговых сценариев. Растет осведомленность об элементе dialog. Но проблем и у нативных, и у пользовательских модальных окон (ARIA) все еще хватает.

dialog, чего ждем?

С момента самой первой реализации элемента dialog в Chrome Canary прошло уже почти 5 лет, но он по-прежнему до конца не реализован.

На данный момент ситуация такая:

• Chrome 37+ и другие браузеры на основе blink поддерживают dialog (Opera 24+, Opera Mobile 46, Android / Chrome android 67).
• В Firefox (53+) еще требуется разрешение для использования.
• Safari (macOs и iOS) не поддерживают элемент, хотя запрос на включение висит с 2012 года
• В Microsoft Edge элемент имеет пометку «рассматривается».
• Наконец, Internet Explorer никогда не будет поддерживать dialog .

В браузерах все довольно печально. Но за последние несколько лет был некоторый интересный прогресс с ARIA и дополнительными методами для создания пользовательских модальных диалогов.

Как должен вести себя модальный диалог

1. Когда модальное диалоговое окно активировано, фокус должен быть перемещен на него. Куда именно зависит от содержимого, но обязательно на окно. Это обеспечивает предсказуемый пользовательский интерфейс.
2. Модальное диалоговое окно должно иметь понятное имя и предоставлять стандартные методы закрытия (кнопка закрытия, нажатие клавиши esc , щелчок мыши или нажатие за пределами окна) и обеспечивать стандартное поведение других команд (например, клавиша F6 по-прежнему должна перемещать фокус клавиатуры в адресную строку браузера).
3. Пока модальное диалоговое окно активно, скрытое им содержимое должно быть недоступно для пользователей. Клавиша TAB и виртуальный курсор программы чтения с экрана (клавиши со стрелками) не должны покидать диалог и перемещаться по содержимому вне его.
4. Когда модальное диалоговое окно закрывается, фокус должен вернуться к элементу управления, который первоначально активировал диалоговое окно. Это позволит пользователям продолжать анализировать документ с того места, на котором они остановились. Если модальное диалоговое окно не было инициировано целенаправленным действием пользователя или элемент, который его активировал, больше не находится в DOM, то закрытие должно поместить фокус в логичное место. Например, если диалог был открыт при загрузке страницы, то фокус можно было поместить либо на ее тело, либо на главный элемент. Если триггер был удален из DOM, то идеально разместить фокус как можно ближе к тому месту, где он был.

Обновления ARIA и использование inert

В ARIA 1.1 был добавлен атрибут aria-model и значение dialog для aria-haspopup . Эти дополнения стали бы огромным подспорьем в создании доступных модальных диалогов более доступными, если бы не некоторые моменты реализации.

aria-modal

aria-modal указывает скринридерам, что пользователю должен быть доступен только контент, содержащийся в диалоговом окне с атрибутом aria-modal= «true» .

Это очень приятное дополнение к спецификации. aria-modal помогает устранить одно из самых больших препятствий в работе с модальными окнами: удерживание программы чтения в активном диалоге. Один лишь JavaScript не способен управлять виртуальным курсором.

Практически во всех сочетаниях программ экранного чтения и браузеров этот атрибут работает, как надо, за одним неудачным исключением. Safari + VoiceOver как на macOS, так и на iOS имеют проблемы с доступностью статического содержимого в модальном окне (см. зарегистрированную ошибку WebKit).

Кроме того, не всегда работает aria-modal=»false» . Но эта проблема гораздо менее серьезна, так как значение false можно просто не использовать.

aria-haspopup

На момент написания этой статьи большинство программ чтения с экрана еще не поддерживают aria-haspopup=»dialog» . Часто они не упоминают о связи элемента управления с диалоговым окном, а некоторые вовсе считают, что это открывающееся меню (поскольку haspopup изначально был связан с меню), что приводит к неожиданному пользовательскому опыту.

До тех пор, пока поддержка значения dialog не реализована должным образом, лучше не использовать aria-haspopup на элементе, который открывает модальное окно. В то же время можно добавить какой-то визуальный и/или скрытый индикатор (значок и/или текст).

inert + aria-hidden= true

Чтобы фокус клавиатуры и виртуальный курсор скринридера не взаимодействовали с контентом при открытом модальном окне, можно использовать атрибут inert (полифилл Google и WICG) в паре с aria-hidden=»true» .

Например, пользователь должен иметь возможность с помощью клавиши F6 переместить фокус в адресную строку браузера. Но когда вернется, inert и aria-hidden=»true» предотвратит фокусировку на элементах, закрытых диалоговым окном.

Добавление aria-hidden=»true» гарантирует, что элементы, не входящие в активный диалог не будут отображаться в списке элементов скринридера. Это неплохое решение, пока не будут решены текущие проблемы с VoiceOver.

Наконец, использование aria-hidden= «true» и inert вместе не дает пользователям VoiceOver покинуть модальный диалог при чтении построчно (с помощью клавиш со стрелками вверх и вниз, без клавиши-модификатора VO). Большинство пользовательских модальных окон не учитывают такую навигацию.

Подводные камни

Помимо вышеупомянутых проблем с aria-modal и aria-haspopup= «dialog» , есть еще несколько, которые следует отметить:

Не используйте display: none для диалогов

В iOS Safari + VoiceOver, если для элемента изначально установлено свойство display: none , то программа не будет фокусироваться на нем, даже если установить фокус из скрипта. Для обхода этой ошибки следует использовать visibility: hidden для неактивного состояния и visibility: visible для отображения диалога. Поскольку модальное окно в большинстве случаев имеет position: fixed (или absolute ), оно не будет занимать физическое пространство в потоке DOM-элементов, visibility можно использовать без опасения.

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

display: block отменяет дефолтное значение none, а visibility: hidden скрывает диалог более выгодным способом.

Чрезмерно подробные объявления NVDA

При тестировании с NVDA установка фокуса на не фокусируемый элемент (например, заголовок с tabindex=»-1″ ) может привести к многократному объявлению этого элемента и содержимого диалогового окна.

Установка фокуса на первый фокусируемый элемент модального окна может привести к несогласованности и плохому пользовательскому опыту (например, если первый фокусируемый элемент — это кнопка «закрыть» в конце объемного диалога, или поле ввода в середине, то предшествующий контент может быть упущен). Лучше просто сфокусироваться на самом диалоговом окне и позволить пользователю ориентироваться самому.

В IE11 заголовок модального окна должен быть его первым элементом

Первым элементом диалога должен быть заголовок (с доступным именем). Это необходимо для связки Internet Explorer 11 + JAWS . Установка фокуса на окно приведет к объявлению его имени и роли, а затем JAWS повторно объявит имя и роль первого дочернего элемента.

Например, если заголовок диалогового окна предоставляет его имя, то JAWS + IE11 объявит текст заголовка, диалог. текст заголовка, уровень заголовка # . Однако, если первым идет другой элемент, например, кнопка с текстом «закрыть», он будет объявлен как: текст заголовка, диалоговое окно. текст заголовка, кнопка .

NVDA не объявляет роль диалогового окна, когда оно получает фокус

NVDA не объявляет роль диалогового окна, если фокус установлен на сам элемент окна. Например, в NVDA + IE11 будет объявлено только имя. В связке с Firefox или Chrome будет объявлено имя диалога, а затем его содержимое.

Выводы

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

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

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

Сайты с модальными диалоговыми окнами без JavaScript

Сайты, которые используют JavaScript для большей части таких элементов, как модальные диалоговые окна, выпадающее меню, мобильные меню-«гамбургеры», зачастую демонстрируют полный провал в плане удобства пользования и доступности. В особенности это верно, когда речь заходит об отсутствии у них постепенной деградации.

Точно так же многие «классические» методы навигации, к примеру выпадающее меню, неудобны для пользователей с ограниченными возможностями. И в NNGroup, и в основных руководствах (том же WCAG) нам регулярно повторяют: не пользуйтесь для этого скриптами, здесь хватает проблем и без них.

CSS3 предоставляет все инструменты, чтобы это исправить. При этом объем кода остается таким же или даже меньшим, а устройства чтения с экрана, считыватели шрифта Брайля, поисковые системы и т. д. способны обработать страницу так же хорошо, как если бы ее составляли только обычные элементы навигации.

И вся эта магия получается благодаря одному простому псевдо-классу :target .

Что такое :target в CSS3?

Этот псевдо-класс позволяет стилизовать элементы, которые в данный момент являются целью хэш-части текущего адреса страницы. Когда этот хэш совпадает либо с именем тега <a>nchor , либо с любым элементом страницы с тем же идентификатором, :target для указанного элемента будет верным.

Именно это применение — таргетинг ID для применения стилей — нам и понадобится. Допустим, у меня есть:

Если в конце URI содержится хэш #test , текст внутри div будет красным. В ином случае будет стоять цвет по умолчанию.

Как же этим воспользоваться, чтобы сделать модальный диалог?

Если элемент не обозначен как :target , спрячьте его. Если наоборот — покажите. Вот и всё переключаемое состояние без всяких скриптов.

Разметка

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

А чтобы закрыть его, внутри модального диалога можно просто поставить:

При изменении хэша на пустое значение, диалог закрывается.

Достаточно поразмыслив над этим, в итоге я остановился на следующей структуре:

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

Назначение внешнего div очевидно: это будет “фиксированный” контейнер, установленный на весь экран. display:flex; в сочетании с align-items:center; и justify-content:center; будут центрировать содержимое. Если у вас есть хоть какой-то опыт работы с flex или center , вы знаете, как они могут поломать прокрутку. Использование Overflow:auto на флекс-контейнерах ненадежно и часто не работает вообще. Поэтому вместо того, чтобы устанавливать flex на внешний контейнер, мы устанавливаем его на первый тег div внутри DIV.modal .

У нас есть два a.modalClose . Снабдим их классами, потому что они могут понадобиться в таких местах, где выбирать их с помощью структуры будет означать переусложнение. Первый из них предназначен для полноэкранного закрытия: то есть, если вы кликните за пределами актуальной области содержимого, он закроет модальный режим. Второй нужен для сгенерированного содержимого и добавляет заметную кнопку закрытия: создает четкое визуальное пятно для завершения диалога, а также работает в тех случаях, когда экран слишком мал, чтобы отображалась область вокруг актуального содержимого в <section> .

Оба этих якоря установлены в hidden и aria-hidden=”true” , так что User-Agent не-экранных медиа будут игнорировать оба элемента. Программы для чтения с экрана, программы для чтения шрифта Брайля, поисковые системы и тому подобные юзер-агенты будут делать вид, что этих якорей не существует. Они не будут фокусироваться на них при навигации по клавиатуре и не будут пытаться читать их содержимое. Их не существует ни в одном современном юзер-агенте, если только мы не нацеливаем их на отображение, изменяя их состояние с помощью CSS. Поэтому при использовании media=”screen” в таблице стилей <link> мы можем включить все необходимое только для устройств с экранными медиа.

Примечание: в 99% случаев, когда вы видите <link> или <style> , в которых отсутствует media=”” , или установлено значение media=”all” , вы смотрите на досадные три “н” веб-разработки: невежество, некомпетентность и неумелость. Вот почему медиа-запросы, которые содержат “screen and” во внешней таблице стилей — такое же невежество. Впрочем, это же в большинстве случаев можно сказать и о <style> или style=”” .

Поскольку div семантически нейтральны, а мы скрываем якоря, юзер-агенты не-экранных медиа и поиск фактически будут рассматривать вышеприведенную разметку так:

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

Обратите внимание: поскольку эти section/nav представляют собой полноправные разделы содержимого, структурно их необходимо начинать их с h2 как разделы верхнего уровня.

Это идеальный вариант! Он решает все проблемы доступности, которые могут возникнуть с модальными диалогами на странице.

Помните: h1 (в единственном числе) — это заголовок (тоже в единственном числе), для которого всё остальное на сайте — подразделы. Как название в верхнем колонтитуле каждой страницы в книге или газете. h2 отмечает начало основных подразделов страницы, h3 — начало подразделов h2 , предшествующих им. h4 отмечает начало подразделов h3 перед ними. Догадаетесь сами, для чего предназначены h5 и h6 ? Даже скромный hr означает изменение темы или раздела, а не просто “провести линию по экрану”.

Вот почему не стоит просто так перескакивать на пятый уровень глубины или начинать документ с h4.

Иные вопросы

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

Самый простой вариант обойти это — дополнительный div в качестве ложного body , который станет двойником модального диалога. Но, как было сказано выше, прокрутка через overflow:auto; ломает flex , поэтому мы добавим дополнительный внутренний div . Таким образом можно добиться от диалога 100% минимальной высоты через флекс.

Обратите внимание: я помещаю закрывающий комментарий перед тегами. Это позволяет избежать ошибок рендеринга в некоторых браузерных движках, где комментарии между элементами уровня родственного элемента или между закрытиями могут рассматриваться как содержимое или вызывать ошибки “двойного рендеринга”. Хотя это не проблема в большинстве современных браузеров, это гораздо лучше, чем помещать комментарии после закрытия.

Также, вероятно, нам захочется воспользоваться теми же самыми методами для главного меню. Однако это будет сделано только в медиа-запросе, чтобы “в норме” это был не модальный диалог. Таким образом, разметка будет выглядеть примерно так:

Я даю заголовку идентификатор #top в качестве якоря для ссылок “назад к началу”. Внешний div получает идентификатор, чтобы a.mainMenuOpen указывал на него. Мы берем nav вместо section , так что вместо дополнительной div -“обертки” можем просто применять ul . Все связанные с модальным диалогом якоря снабжаются тем же самым hidden и aria-hidden=”true” , так что программы чтения с экрана игнорируют их.

Стиль

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

Затем нам нужно разместить все контейнеры, связанные с модальными диалогами, включая #fauxBody .

Обычно вы бы применяли position:fixed , но на самом деле это может вызвать проблемы с прокруткой и позиционированием в Webkit. Поскольку всё это — дочерние элементы body , все они с полным размером экрана, а всё содержимое будет размещаться внутри этих контейнеров, ту же функцию может взять на себя position:absolute .

Отсюда займемся модальными диалогами.

Поскольку тут уже есть width:100% и overflow:auto , то, чтобы скрыть их, нам нужно только сдвинуть их с левой стороны экрана по видимой ширине. НЕ ИСПОЛЬЗУЙТЕ ДЛЯ ЭТОГО DISPLAY:NONE; ИЛИ VISIBILITY:HIDDEN; ! Это помешает поисковым системам, ищущим злоупотребления маскировкой контента, и не позволит им увидеть содержимое этих элементов.

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

И затем отображаем его. Здесь как раз начинается реализация функциональности. Left:0 для показа и постепенное проявление непрозрачности, чтобы было красиво.

С внутренним div :

С помощью флекса отцентрируем section и nav :

Делаем любой стиль, который мы хотим. Я использую transform:scale animated так, чтобы, когда модальный диалог является целью target , он “масштабировался” в фокус.

Получаем сгенерированный контент UTF-8, который затем с помощью абсолютного позиционирования ставим над нашим h2 .

А дальше уже можно заняться нормальной стилизацией компонентов.

Главное меню должно находиться внутри медиа-запроса, поэтому нам нужно скопировать большую часть того же кода. Не самый лучший вариант, так как мы его просто удваиваем. Тем не менее как-то иначе обойти это нельзя. (Если бы только “empty” в CSS3 и общий селектор сиблингов работали в сгенерированном содержимом!)

Сначала мы делаем “гамбургер” через сгенерированный контент и границы.

Затем прописываем target для .modalClose , чтобы он стал видимым.

И то же самое для .modal :

И так далее, и тому подобное. В общем, идея ясна. Еще одна забавность, которую мы можем сделать с меню, — вместо заголовка h2 воспользоваться сгенерированным содержимым для добавления ложного заголовка.

Обеспечиваем визуальную согласованность.

Наглядная демонстрация

Вы можете посмотреть, как это работает, здесь:

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

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

Плюсы и минусы

Начнём в первую очередь с проблем.

Недостатки

1. Множественные открытия-закрытия могут заполнить историю браузера.
2. Для согласованности необходимо в точности следовать разметке за пределами самого внутреннего div . Это можно счесть “хрупкой разметкой”.
3. CSS-селекторы могут показаться сложными, особенно если вы считали, что они замедляют рендеринг.
4. В конечном итоге вы получаете дополнительную разметку вокруг контента. Имейте в виду: если вы делаете макет с минимальной высотой, то, скорее всего, у вас уже есть такая разметка!
5. Этот метод опирается на функции, которых нет в ряде устаревших браузеров. В частности, могут возникнуть проблемы с IE. В таком случаене отправляйте CSS в IE, оставив чистую разметку.

Преимущества

1. Использование семантики, hidden и aria-hidden приводит страницу в стопроцентное соответствие минимальным требованиям доступности.
2. Никакого JavaScript. Это не только убирает проблемы с доступностью, но и приводит к тому, что действия срабатывают более плавно и чисто. В отличие от многих JavaScript “фреймворков”, которые занимаются этим через “вычисления” на основе таймера.
3. Последовательная структура позволяет легко и просто копировать существующие примеры в новые конструкции.
4. Избыточные классы сведены к минимуму, что приводит к лучшему использованию моделей кэширования. Помните: не нужно писать в разметке пространных описаний, будь то ваши тэги, идентификаторы или классы. Просто называйте их своими именами. Чем больше презентации вы добавите в разметку — даже в виде классов — тем медленнее будет страница. Вот почему заявления, будто бы присваивание классов всему подряд, например через BEM, каким-то волшебным образом делает страницу “быстрее” или “лучше”, неверны.
5. Поскольку всё это управляется CSS, очень легко переключать анимации по вашему усмотрению. Просто играйте с трансформацией, переходами и позиционированием.

Почему стоит отказывать от JavaScript

До сих пор мы изо всех сил старались избегать использования JavaScript, но это не значит, что мы не можем или не должны его применять.

Например, нас может не волновать, как он заполняет историю браузера. Вы можете подключить ко всем якорям .modalClose указания, что если предыдущий хэш пуст, но страница осталась та же, вместо якоря должно срабатывать window.history.back() .

Если тогда вы позволите себе JavaScript — это нормально. Но только тогда. Пусть всё, что может работать без JavaScript, работает без него. Сначала сосредоточьтесь на нормальной загрузке страниц и нормальной навигации по содержимому. Качественный JavaScript должен улучшать уже работающую страницу, а не оставаться единственным средством обеспечения функциональности.

Если сайт не адаптирован для людей с ограниченными возможностями, то за это можно понести юридическую ответственность. Более того, множество пользователей просто не смогут воспользоваться вашим продуктом. Именно поэтому так важно взять на вооружение правильную семантику и логическую структуру, а также учитывать, что происходит с изображениями, скриптами и даже CSS. Мы должны помнить, что CSS имеет медиа-цели (экран, печать, речь и т. д.), и если вы не прописываете их, когда используете <link> или <style> или отправляете “всем”, то они могут создавать проблемы с доступностью — или просто зря тратить пропускную способность.

Скорость также играет роль. Не стоит применять гигантский JS-фреймворк с тысячами строк индивидуальных скриптов, чтобы выполнить то, с чем могут справиться четыре-шесть тысяч строк CSS. Даже некоторые клиенты начинают сосредотачиваться на таких параметрах, как “значимое время отображения” в инструментах вроде Lighthouse, а раздутые медленные скрипты и огромные “фреймворки” могут поставить на этом крест.

Как веб-профессионалы, мы просто должны начать думать в этом направлении.

Вывод

Избегая JavaScript в пользу CSS3, можно создавать страницы, доступные для пользователей с ограниченными возможностями, и дополнять их модными экранными эффектами. Благодаря современным функциям браузера гораздо проще и полезнее сначала написать семантику, добавить несколько div , настроить таргетинг таблицы стилей для экранных медиа, а затем использовать селекторы и псевдо-классы для запуска поведения, а не тратить время на написание скриптов для обработки всего этого.

И еще вот что: разделение интересов. Как бы странно это ни звучало, но если вы взглянете на семантическую навигацию без экранного CSS, то модальные диалоги, по крайней мере реализованные таким образом, нельзя будет назвать поведением. Это представление. А представления — это то, чем и занимается CSS!