Короткий ответ
Приёмка сайта — это несколько часов работы по списку, а не общее впечатление от главной. Начинаем с телефона на слабом соединении, проверяем формы до получателя, сверяем доступность по WCAG 2.2 и собираем замечания в один документ.
Приёмка сайта: короткий ответ
Приёмка — это структурированная проверка готового сайта на соответствие тому, что вы заказывали, которая проводится до финального платежа и до подписания акта. Она занимает несколько часов и делается по письменному списку, а не по общему впечатлению от главной страницы.
Порядок проверки такой: сначала телефон на слабом соединении, затем содержимое страниц против брифа, затем формы до получателя, затем доступность по WCAG 2.2, затем навигация, поведение при загрузке и панель управления. Все находки собираются в один документ.
Приёмка не про поиск виноватых. Её задача — получить письменный перечень того, что работает и что нужно поправить, и убедиться, что этот перечень укладывается в раунды правок, оговорённые в вашем пакете, а не выходит за них.
Дальше в статье двенадцать блоков проверки. Каждый из них проходится без специальных инструментов: нужен телефон, ноутбук, браузер и час спокойного времени, когда вас не отвлекают вопросами по другим задачам.
Что подготовить до начала проверки
До первого клика соберите три документа: бриф или техническое задание, перечень страниц и функций, которые входили в работу, и переписку, где согласовывались изменения по ходу проекта. Без них проверка превращается в обсуждение вкусов.
Запросите адрес, на котором проводится приёмка. Это может быть тестовый домен или уже боевой адрес, но он должен быть один и тот же для вас и для подрядчика, иначе вы будете обсуждать разные версии одной страницы.
Возьмите два устройства: свой обычный телефон и ноутбук. Не проверяйте только на рабочей машине с быстрым интернетом и широким монитором — она показывает сайт в условиях, которых у ваших посетителей может не быть никогда.
Заведите пустую таблицу с колонками: страница, что происходит, что ожидалось, устройство и браузер, приоритет. В неё вы пишете по ходу дела, а не пытаетесь через два дня вспомнить формулировку найденной ошибки.
Начните с телефона и медленного соединения
Откройте сайт на телефоне раньше, чем на ноутбуке. Ошибки вёрстки, которые незаметны на широком экране, на узком становятся видимыми сразу, и встретить их лучше сейчас, а не в сообщении от клиента.
Отключите Wi-Fi и работайте через мобильную сеть, а если есть возможность — в месте со слабым сигналом. Там быстрый офисный интернет перестаёт прятать вещи: задержку до первого читаемого текста, прыгающую вёрстку и картинки, которые приезжают последними.
На телефоне проверьте три вещи: помещается ли текст без горизонтальной прокрутки, попадаете ли вы пальцем по кнопкам и ссылкам, и не перекрывает ли липкая шапка или баннер согласия то, ради чего человек пришёл на страницу.
Документация MDN по производительности описывает не только скорость загрузки, но и воспринимаемую производительность — ощущение отзывчивости интерфейса. Именно это ощущение вы и проверяете, когда открываете сайт на телефоне в дороге, а не на столе разработчика.
Сверка содержимого: бриф против опубликованной страницы
Откройте перечень страниц из брифа и пройдите по нему построчно. Каждая обещанная страница должна существовать, открываться по прямой ссылке и содержать тот блок, ради которого её заказывали, а не абзац временного текста-заглушки.
Прочитайте тексты, выискивая опечатки, старые цены, чужие названия и остатки демонстрационных данных. Здесь стоит помнить: VITON13 не пишет за клиента тексты и не делает переводы — содержимое передаёт заказчик, поэтому вычитка слов остаётся зоной вашей ответственности.
Сверьте контактные данные во всех местах, где они встречаются: в шапке, в подвале, на странице контактов, в микроразметке и в сообщении об отправке формы. Расхождение хотя бы в одной цифре телефона тихо стоит вам звонков.
Отдельно посмотрите на изображения: правильные ли товары, нет ли водяных знаков фотобанков, соответствует ли ориентация макету. Проверьте и альтернативные описания к картинкам — по WCAG 2.2 это критерий 1.1.1 «Нетекстовый контент» уровня A.
Формы: проверка до получателя, а не до кнопки
Форма считается принятой не тогда, когда кнопка отзывается на нажатие, а когда заявка доходит до человека, который на неё отвечает. Проверять до кнопки — значит принять половину функции и узнать об остальном от потерянного клиента.
Отправьте тестовую заявку с настоящими данными и проследите весь путь: экран благодарности, письмо на почту компании, письмо клиенту, запись в CRM или в таблице, если она входила в объём работ. Каждый шаг отмечайте отдельной строкой.
Затем сломайте форму намеренно: отправьте пустую, введите телефон буквами, укажите почту без символа собаки, приложите слишком большой файл. Сообщения об ошибках должны быть текстом рядом с полем и объяснять, что именно нужно исправить.
По WCAG 2.2 это критерии 3.3.1 «Идентификация ошибки» и 3.3.2 «Метки или инструкции» уровня A, а также 3.3.3 «Предложение по исправлению» уровня AA. Красная рамка и слово «Ошибка» без пояснения этим критериям не соответствуют.
Доступность: что проверить по WCAG 2.2 самостоятельно
WCAG 2.2 — это рекомендация W3C с тремя уровнями соответствия: A, AA и AAA. Если в вашем договоре уровень не назван, ориентируйтесь на AA и учитывайте, что заметная часть его критериев проверяется руками, без аудитора и платных инструментов.
Контраст текста по критерию 1.4.3 уровня AA — не ниже 4,5:1 для обычного текста и 3:1 для крупного. Границы полей, иконки и элементы управления подпадают под критерий 1.4.11, где порог составляет 3:1.
Критерий 2.5.8 «Размер цели (минимальный)» уровня AA, добавленный в версии 2.2, требует области нажатия не меньше 24 на 24 CSS-пикселя, с оговорёнными в нём исключениями. Посмотрите мелкие иконки в подвале и стрелки в галереях.
Ещё два дополнения версии 2.2 относятся к проверке форм: 3.3.7 «Повторный ввод» уровня A, по которому уже введённые в том же процессе данные не должны запрашиваться заново без необходимости, и 3.3.8 «Доступная аутентификация» уровня AA, если на сайте есть вход.
Клавиатура, фокус и масштабирование
Уберите руку с мыши и пройдите главную страницу клавишей Tab. Вы должны всё время видеть, где находится фокус, порядок перехода должен совпадать с визуальным, а меню, модальные окна и плееры обязаны отпускать вас обратно.
Это критерии 2.1.1 «Клавиатура» и 2.1.2 «Отсутствие ловушки клавиатуры» уровня A, а также 2.4.7 «Видимый фокус» уровня AA. В версии 2.2 добавился критерий 2.4.11 «Фокус не перекрыт (минимум)» уровня AA — его стоит проверить на липких шапках.
Проверьте масштабирование: увеличьте текст до 200 процентов, поскольку критерий 1.4.4 уровня AA требует, чтобы содержимое и функции оставались доступными. Затем сузьте окно браузера примерно до 320 CSS-пикселей и убедитесь, что горизонтальная прокрутка не появилась.
Если в интерфейсе есть перетаскивание — сортировка карточек, ползунок диапазона, область для файлов, — критерий 2.5.7 уровня AA требует альтернативы одним указателем, не требующей самого жеста, кроме случаев, когда перетаскивание существенно для задачи.
Навигация, ссылки и состояния ошибок
Пройдите по всем пунктам меню и по всем ссылкам в подвале. Каждая должна вести на существующую страницу этого сайта, а не на черновик, не на домен подрядчика и не на страницу, которую вы просили убрать несколько недель назад.
Наберите в адресной строке заведомо несуществующий адрес. Вы должны увидеть страницу 404 в дизайне сайта, с меню и с выходом на главную, а не системное сообщение сервера и не белый экран с технической строкой.
Проверьте пустые состояния: поиск без совпадений, корзина без товаров, каталог с фильтром, под который ничего не подходит. В каждом случае посетитель должен понимать, что произошло и что он может сделать дальше.
Загляните и в служебные вещи: заголовок вкладки на каждой странице должен отличаться и описывать её — это критерий 2.4.2 уровня A, — а язык страницы должен быть объявлен, критерий 3.1.1 того же уровня.
Скорость и поведение при загрузке
Скорость оценивается на том же телефоне и в той же сети, а не в отчёте, составленном в идеальных условиях. Откройте сайт с холодного старта, без ранее сохранённых данных, и посмотрите, через сколько появляется первый читаемый текст.
Обратите внимание на смещения вёрстки. Если текст уже читается, а затем его сдвигает вниз поздно загрузившаяся картинка или баннер, это дефект приёмки, а не особенность. Такие сдвиги приводят к случайным нажатиям и к потере места чтения.
В инструментах разработчика браузера есть ограничение сети, которое имитирует медленное соединение. Документация MDN по производительности настаивает на том, что измерять стоит и загрузку, и отзывчивость интерфейса, а не одну заголовочную цифру.
Не требуйте от подрядчика конкретной оценки в стороннем сервисе, если её не было в договоре. Формулируйте замечание через поведение: на телефоне через мобильную сеть первый экран появляется заметно позже, чем на ноутбуке. Это можно проверить.
Админка и CMS: сможете ли вы редактировать сами
Войдите в панель управления под своей учётной записью, а не под учётной записью разработчика. Убедитесь, что у вас роль владельца или администратора и что вы видите все разделы, которые обсуждались как редактируемые вашими силами.
Внесите настоящую правку: измените заголовок на одной странице, добавьте абзац, загрузите изображение, сохраните и посмотрите результат на публичной версии. Если для любого из этих действий нужен разработчик, эта часть работы ещё не принята.
Проверьте, что редактирование не ломает вёрстку: длинный заголовок должен переноситься, а не выезжать за блок, а изображение непредусмотренного размера должно вписываться. Вставьте намеренно очень длинное слово и очень длинный абзац.
Договоритесь о границе. Содержимое правите вы, шаблоны и логику меняет подрядчик. В пакете «Постоянная техническая поддержка» за $290 в месяц объём таких работ согласуется в начале каждого цикла.
Как оформить список замечаний и уложиться в раунды правок
Отправляйте одно письмо с одним списком, а не десять сообщений в течение дня. Каждый пункт называет страницу, устройство, что произошло, что ожидалось, и по возможности содержит скриншот. Сообщение «как-то не так смотрится» вернётся к вам вопросом.
Разделите список на две части: то, что мешает пользоваться сайтом, и то, что вы теперь предпочли бы иначе. Первое — дефекты, второе — новые пожелания, и на сроки и на оплаченные правки они влияют по-разному.
Число раундов зависит от пакета и не переносится с одного на другой. «Сайт для запуска» за $380 со сроком 3-5 рабочих дней включает два раунда правок до запуска. «Разработка продукта» за $880 со сроком 2-3 недели включает два раунда на каждую сданную функцию.
Site Fix Pack за $70 со сроком 1-2 рабочих дня — это один раунд и до пяти согласованных исправлений с проверкой на мобильном и десктопе и списком «было — стало» при передаче. Launch Site Express за $520 со сроком 2 рабочих дня — один раунд после первой полной сборки.
Подписание и что происходит после приёмки
Подписывайте акт тогда, когда пункты вашего списка закрыты и перепроверены на том же телефоне, с которого вы начинали. Второй проход занимает заметно меньше времени, чем первый, потому что маршрут по сайту вам уже известен.
Зафиксируйте письменно, что осталось за рамками работы: тексты и переводы, если по договорённости они на вашей стороне, или нативные мобильные приложения и лицензирование платёжных решений, которые не входят в «Разработку продукта».
Решите, что происходит с сайтом дальше. Разовые доработки после запуска ложатся в Site Fix Pack, а приоритетные обновления, недельный ритм релизов и техническое обслуживание относятся к «Постоянной технической поддержке» за $290 в месяц с помесячным циклом и уведомлением за 30 дней при остановке.
И сохраните сам чек-лист. Через полгода, когда вы будете принимать следующую доработку или менять подрядчика, уже пройденный маршрут проверки сэкономит вам вечер и закроет спор о том, что именно считается сделанным.
Практический чеклист
- Откройте сайт на своём телефоне через мобильную сеть, а не через офисный Wi-Fi.
- Пройдите список страниц из брифа и отметьте всё, чего нет или что стоит заглушкой.
- Отправьте тестовую заявку и проследите её до почты компании, до клиента и до CRM.
- Пройдите главную страницу клавишей Tab и проверьте видимость фокуса и выход из модальных окон.
- Проверьте контраст текста и размеры целей нажатия по критериям 1.4.3, 1.4.11 и 2.5.8.
- Соберите замечания в одну таблицу с приоритетами и отправьте их одним письмом.
Вопросы и ответы
Сколько времени занимает приёмка сайта?
Закладывайте несколько часов сосредоточенной работы, а не беглый просмотр. Время уходит на прохождение письменного списка с телефона и с ноутбука, на отправку тестовых заявок и на запись найденного. Разбить проверку на два подхода можно, а вот присылать находки десятью отдельными сообщениями не стоит.
С какого устройства начинать проверку?
Со своего телефона через мобильную сеть, а не через офисный Wi-Fi. Широкий монитор с быстрым интернетом скрывает ошибки вёрстки на узком экране, поздно приезжающие изображения и задержку до появления первого читаемого текста.
Сколько раундов правок входит в пакеты разработки?
Зависит от пакета, и с одного на другой они не переносятся. Site Fix Pack за $70 со сроком 1-2 рабочих дня — один раунд. «Сайт для запуска» за $380 со сроком 3-5 рабочих дней — два раунда до запуска. «Разработка продукта» за $880 со сроком 2-3 недели — два раунда на каждую сданную функцию. Launch Site Express за $520 со сроком 2 рабочих дня — один раунд после первой полной сборки.
Что делать, если ошибки нашлись уже после подписания?
Небольшие и точно описанные исправления укладываются в Site Fix Pack за $70: до пяти согласованных правок за 1-2 рабочих дня, с проверкой на мобильном и десктопе и списком «было — стало» при передаче. Новые страницы, редизайн и миграции в него не входят. Для регулярного ритма есть «Постоянная техническая поддержка» за $290 в месяц с помесячным циклом и уведомлением за 30 дней при остановке, где объём работ согласуется в начале каждого цикла.
Нужно ли проверять доступность, если сайт небольшой?
Перечисленные проверки WCAG 2.2 не требуют аудитора и платных инструментов: контраст, порядок обхода клавиатурой, видимый фокус, размер целей нажатия и понятные ошибки в формах. Попутно они ловят обычные проблемы удобства, потому что слишком мелкая кнопка и сообщение «Ошибка» без пояснения мешают всем посетителям.