Доступность… на бэкэнде?

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

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

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

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

Производительность

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

• Производительность может быть решающим фактором для пользователя при совершении покупки , а отсутствие производительности на сайте может привести к потере потенциальных клиентов;
• Google рассматривает показатель производительности сайта как критерий ранжирования в поиске .

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

Интернационализация

Интернационализация — это доступность. На практике оба метода имеют общую цель: сделать контент на экране понятным пользователю .

Это работа, которая во многом зависит от того, будет ли разрабатываемое приложение рассматриваться как «доработка» или «передовая работа» (или и то, и другое), но факт остается фактом: когда вы разрабатываете что-то, предназначенное для многоязычия, работа должна быть сделано последовательной интернационализации. Кто никогда не заходил на сайт, «переведенный» на португальский язык, но замечал несколько текстов на английском языке? Да, не следуйте этому примеру.

Ой! Это кажется слишком простым, чтобы даже упоминать об этом, но в повседневной жизни об этом очень часто забывают: используйте атрибут langв HTML, обычно он используется в корневом элементе страницы (теге html), но также может использоваться, когда определенная часть страницы это на другом языке, чем остальная часть сайта. Этот атрибут очень важен для браузера, чтобы определить язык, используемый на странице, и предложить автоматические переводы на основе языка браузера пользователя.

изучить основы

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

Поговорите с коллегами из других областей

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

Ограничение времени на выполнение действий

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

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

• События в реальном времени: должно быть ограничение по времени для действия, такого как онлайн-аукцион.
• Действия, для которых время имеет существенное значение: время имеет существенное значение, и увеличение лимита сделает действие недействительным, например, предложение с ограниченным сроком действия на сайте электронной коммерции.
• Ограничение в 20 часов: хотя маловероятно, что задача будет выполняться более 20 часов подряд, это было выбрано W3C в качестве ограничения, после чего разрешено ограничение по времени.

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

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

повторная аутентификация

Представьте себе следующий сценарий:

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

«Какая-то» скучная ситуация, верно? Так что, это.

Хорошо, это проблема, но какое это имеет отношение к доступности?

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

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

• Периодически продлевать время сеанса, пока пользователь активен на сайте;
• Резервировать тикет и сохранять данные формы по мере ввода пользователем, на тот случай, если он по какой-то причине не сможет завершить заполнение и захочет продолжить позже;
• Предоставьте возможность повторной аутентификации, не покидая текущую страницу, и продолжите процесс после повторной аутентификации.

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

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

Заключение

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

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

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

Рекомендации

• Да, доступность также является проблемой бэкенда (Эрик Бейли)
• Регулируемое время — время ограничивает требуемое поведение (W3C)
• Сокращения (W3C)