Проверить доступность страницы через инструменты разработчика можно в браузере: изучите HTTP-статус, перенаправления, сетевые запросы и ошибки JavaScript. Такая проверка доступности сайта помогает понять, отвечает ли сервер и загружаются ли ресурсы, но сама по себе не подтверждает корректность дизайна, содержание страницы или её доступность для людей с инвалидностью.
Что проверить перед диагностикой страницы
- Уточните полный адрес страницы, включая протокол и путь.
- Проверьте, что у вас есть доступ к странице и диагностируете свой сайт либо имеете разрешение владельца.
- Запишите, что именно не работает: страница не открывается, отображается частично или ведёт себя неправильно.
- Подготовьте браузер с инструментами разработчика; для сравнения результата используйте режим инкогнито.
- Не отключайте защиту браузера и не меняйте настройки безопасности ради проверки.
Подготовьте адрес и откройте инструменты разработчика
Проверка подойдёт владельцу сайта, редактору или специалисту, которому нужно локализовать проблему при загрузке страницы. Для неё достаточно браузера и адреса страницы. Если вы проверяете сайт, к которому у вас нет разрешённого доступа, ограничьтесь обычным открытием страницы и не пытайтесь обходить ограничения.
В Chrome откройте страницу, затем нажмите F12 или сочетание клавиш Ctrl+Shift+I в Windows и Linux либо Cmd+Option+I в macOS. Также можно открыть меню браузера и выбрать инструменты разработчика. Проверка доступности сайта в Chrome удобна тем, что вкладки Network и Console показывают сетевые события и сообщения страницы.
Проверка доступности сайта и аудит доступности сайта - не одно и то же. Инструкция ниже касается загрузки страницы и её ресурсов. Она не заменяет отдельную проверку удобства интерфейса и соответствия требованиям доступности для людей с инвалидностью.
Проверьте HTTP-статус и цепочку перенаправлений во вкладке Network
Для проверки понадобятся адрес страницы и браузерные инструменты разработчика. Специальные доступы не нужны, если страница общедоступна. Откройте Network до перезагрузки страницы, чтобы увидеть запросы, которые браузер отправляет при загрузке.
- Включите запись сетевых запросов во вкладке Network.
- Перезагрузите страницу и найдите основной запрос документа. Обычно он имеет тип Doc или Document и содержит адрес страницы.
- Посмотрите статус ответа. Успешный ответ означает, что сервер ответил на запрос; ошибка или отсутствие ответа указывают на проблему, но её причину нужно уточнить по другим запросам и сообщениям.
- Проверьте перенаправления. Если документ проходит через несколько адресов, изучите каждый переход и убедитесь, что конечный URL ожидаемый.
- Откройте проблемный запрос, чтобы посмотреть его заголовки и ответ, если браузер показывает эти сведения. Не публикуйте в открытом доступе данные, содержащие токены, идентификаторы сессии или другую чувствительную информацию.
Ответ сервера на запрос документа не гарантирует, что страница отобразится полностью: для этого браузеру также нужно загрузить и обработать связанные файлы.
Убедитесь, что браузер не блокирует загрузку из-за ошибок сети или CORS
Перед пошаговой проверкой подготовьте адрес страницы, откройте DevTools и оставьте вкладку Network доступной. Если проблема касается авторизованной страницы, войдите обычным способом; не передавайте диагностирующим лицам пароль, cookie или токены.
- Включите запись запросов. Во вкладке Network проверьте, что запись активна. При необходимости включите сохранение журнала между переходами, если этот параметр доступен в вашем браузере.
- Перезагрузите страницу. Обновите её обычным способом и дождитесь завершения загрузки. Смотрите на запросы со статусом ошибки и на ресурсы, которые долго остаются незавершёнными.
- Найдите заблокированные запросы. Откройте запрос и изучите отображаемую браузером причину. Сообщения об ошибке сети могут указывать на недоступность ресурса, а сообщения CORS - на то, что политика безопасности не разрешила странице получить ответ с другого источника.
- Сопоставьте запрос с адресом страницы. Проверьте, загружается ли ресурс с того же домена или с другого источника, и не отличается ли протокол. Запишите адрес проблемного ресурса и текст ошибки, не копируя секретные параметры из URL.
- Повторите безопасную проверку. Перезагрузите страницу ещё раз и сравните результат. Если ошибка сохраняется, передайте владельцу сайта адрес ресурса, текст сообщения и время проверки; не отключайте политики браузера и не пытайтесь обходить CORS.
Найдите сбои JavaScript и ошибки рендеринга в Console
Откройте Console и повторите загрузку страницы, чтобы сопоставить сообщения с моментом возникновения проблемы. Проверьте результат по списку:
- Есть ли сообщения об ошибках, а не только предупреждения или информационные записи.
- Указывает ли ошибка на конкретный файл и строку кода.
- Не сообщает ли браузер, что скрипт не удалось загрузить или выполнить.
- Возникает ли ошибка при каждой перезагрузке или только после определённого действия.
- Появляется ли ошибка на странице, где проблема видна, и исчезает ли при открытии другой страницы.
- Не связана ли часть ошибок с блокировкой сетевых запросов, проверенной во вкладке Network.
Наличие ошибки в Console не всегда означает, что вся страница недоступна. Сопоставьте сообщение с видимым результатом и с запросами во вкладке Network.
Проверьте загрузку критичных файлов и содержимого страницы
Во вкладке Network убедитесь, что загружаются ресурсы, необходимые для работы и отображения страницы. Частые причины неполной загрузки:
- основной документ не получен или вернул ошибку;
- файл стилей не загрузился, поэтому страница отображается без ожидаемого оформления;
- ошибка загрузки скрипта нарушила работу отдельных функций;
- изображения или другие медиафайлы не загрузились;
- ресурс запрошен по адресу, который больше не существует;
- запрос заблокирован политикой браузера или ограничениями сайта;
- загрузка страницы зависит от ответа другого сервиса, который сейчас недоступен.
Оценивайте каждый сбой по его влиянию: сервер может отвечать на запрос документа, хотя отдельный файл не загружается. Чтобы провести проверку сайта на доступность онлайн, можно использовать веб-сервис проверки, если он подходит для публичного адреса и не требует передавать конфиденциальные данные. Для локализации ошибок браузера полезны и инструменты для проверки доступности сайта, встроенные в DevTools.
Сравните результат в режиме инкогнито и без расширений
Если страница загружается не у всех или ошибка не повторяется стабильно, сравните условия открытия. Используйте эти варианты, не меняя настройки безопасности:
- Режим инкогнито. Подходит, чтобы проверить, влияет ли обычная пользовательская сессия или часть расширений. Учтите, что настройки и разрешения расширений в этом режиме могут отличаться.
- Отключение расширений в обычном профиле. Уместно, если в инкогнито проблема исчезла. Отключайте расширения по одному через настройки браузера и повторяйте загрузку, затем верните нужные расширения.
- Другой поддерживаемый браузер. Используйте его, если нужно понять, связана ли ошибка с конкретным браузером. Сравнивайте один и тот же адрес и фиксируйте различия в сообщениях.
- Повторная проверка позже. Уместна при временной сетевой ошибке. Если сбой повторяется, передайте результаты владельцу сайта или службе поддержки.
Различия между проверками помогают сузить круг причин, но не доказывают, что сервер или сайт исправен для всех пользователей.
Разбор типичных затруднений при проверке доступности
Страница открылась, значит ли это, что сайт работает полностью?
Нет. Основной документ мог загрузиться, а стили, скрипты или изображения - нет. Проверьте запросы во вкладке Network и ошибки в Console.
Что означает успешный HTTP-статус, если страница отображается неправильно?
Это означает, что сервер ответил на запрос документа соответствующим образом. Причина неправильного отображения может быть в сбое скрипта, незагруженном файле или ошибке обработки страницы.
Как отличить сетевую ошибку от ошибки CORS?
Ориентируйтесь на текст, который показывает браузер в Network или Console. Ошибка CORS связана с ограничением доступа страницы к ответу с другого источника; не обходите это ограничение настройками браузера.
Почему в режиме инкогнито страница работает иначе?
В инкогнито могут отличаться состояние сессии, данные сайта и доступность расширений. Сравните запросы и сообщения в DevTools, затем проверьте расширения обычного профиля.
Можно ли проверить закрытую страницу без авторизации?
Нет: для диагностики страницы, доступной только после входа, используйте разрешённую учётную запись. Не передавайте пароль или данные сессии третьим лицам.
Можно ли считать проверку в DevTools аудитом доступности?
Нет. DevTools помогает диагностировать загрузку страницы и ошибки браузера, но такая проверка не оценивает полноценно доступность интерфейса для людей с инвалидностью.