Клиент вписал в контракт жёсткие требования по доступности — у них работают слепые и глухие сотрудники, и им предстоит пользоваться тем, что мы строим. Я думал, обойдёмся парой правок за пару часов. В итоге ушло 18 часов чистой работы.
Проект — approval workflow в Microsoft Power Automate. Ревизию вела их штатная специалистка по доступности, которая сама не видит и будет реальным пользователем системы. Я планировал дать ей доступ к своему браузеру, прогнать workflow и посмотреть. Не сработало. Браузерные приложения Microsoft, по её словам, плохо дружат со screen reader'ами — она не могла нормально по ним перемещаться. Пришлось выдать отдельные права, чтобы она тестировала из своего аккаунта в десктопных приложениях. Мы даже до workflow не дошли, а платформа уже мешала.
Когда наконец запустились, созванивались в Zoom (не случайно — она считает его самым доступным из всех видеоконференций). Она шарила экран, проходила workflow как реальный пользователь, я слушал вместе с ней, как screen reader читает страницу вслух. В этот момент проблема перестала быть абстрактной. Оказалось, что интернет, по которому я скольжу взглядом и кликаю — почти другой мир для того, кто его слушает.
Вот где вылезло самое бесячее. Я сделал страницу в SharePoint, где пользователи видят статус заявок. Страницу надо шарить read-only, чтобы никто случайно не поломал процесс. SharePoint при этом добавляет «(read only)» к каждому-единственному-полю. Зрячий это игнорирует. А screen reader читает эту фразу на каждой строке снова и снова. Представьте фильм, где после каждой реплики диктор говорит «(сказано вслух)». Для пользователей с брайлевским дисплеем это ещё и физически занимает место — каждый лишний символ вытесняет полезный контент.
Я долго искал способ спрятать эти теги. Не нашёл. Это просто то, как работает SharePoint. И так было снова и снова: проблема не в реализации, а в платформе. Нативное приложение Power Automate Approval в Teams screen reader'ы не распознают. JAWS (один из самых популярных screen reader'ов) не читает approval-письма в Outlook. SharePoint генерирует несколько H1-заголовков на одной странице, хотя для незрячего заголовки — не визуальный выбор, а единственный способ навигации. Два H1 — это ложный ориентир, дезориентирует.
Я не пишу это, чтобы бросаться в Microsoft. Так происходит по всей индустрии, когда доступность считают проблемой кого-то другого или галочкой напоследок. Просто Microsoft делает инструменты, на которых мы строим, так что их дыры становятся нашими дырами.
Где мог — исправил. Убрал лишние лейблы, добавил осмысленный alt text, почистил структуру заголовков. Для страницы отслеживания в SharePoint перекроил всё: вместо того чтобы заставлять пользователей продираться через шум, система теперь шлёт email на каждом этапе approval. Четыре-пять писем на заявку. Для кого-то многовато, но для тех, кому нужно — они вообще не касаются недоступной страницы.
Где не мог исправить — делали обходные пути. Вместе написали документацию: честно указали, что не смогли поменять, и как с этим жить. Неприятно писать такое, но необходимо.
Я и сам пользовался screen reader'ом в процессе. Самое неожиданное — не конкретные баги, а шум. Куча лейблов, индикаторов статуса, повторяющихся фраз, структурного мусора, который зрячий фильтрует не задумываясь. Когда ты слушаешь страницу, каждое лишнее слово — это препятствие на пути к тому, зачем ты пришёл.
Большинство софта пишут и тестируют люди, которые видят и слышат. Это не обвинение, а факт. И дыры остаются невидимыми, пока не появится тот, кто с ними живёт, и не проведёт тебя за руку. Мне повезло, что у клиента был такой человек и что они заложили на это реальное время в контракте. Не у каждого проекта будет такое. Но можно начать и без контракта: встраивать стандарты доступности с самого начала, спрашивать, работает ли ваш софт для всех в команде, и сообщать вендорам о сломанных вещах вроде «(read only)» на каждом поле. Чем больше людей жалуется, тем сложнее оставлять это в бэклоге.