Дуже цікавий поінт. Якось не довелось ще попрацювати з такими застосуваннями. Подивлюсь як буде час, а там може і назбираю щось на окрему статтю. Дякую за ідею!

Є 2 можливих варіанта:
1. Заказати сторонній аудит. Є багато компаній, які цим займаються.
Плюси: Ви отримаєте репорт з проблемами. Але цей репорт частіше всього потребую час на те, щоб зрозуміти проблему.
Мінуси: Це, звісно, коштує грошей. Також необхідно витратити час на вибір аудитора та на аналіз репорту. Також частина такіх організацій, нажаль, тестують лише за допомогою автоматичних інструментів. Жоден інструмент не зможе покрити 100% стандарту.
2. Зробити аудит самому. Частіше всього це робиться наступним чином. Сайт ділиться на однорідні типи сторінок. Потім кожен тип сторінок тестується згідно кожного пункту стандарту залежно від того, який рівень ви хочете досягнути.
Плюси: У Вас більше контексту ніж у сторонньої організаціі, тому ви можливо зможете знайти більше проблем. Не потрібно платити сторонній організації. Але це може бути спірним, адже Ваш час теж коштує грошей.
Мінуси: Потрібен час не те, щоб розібратись із стандартом.

Знайшов ще два приклади з репортами по версії 2.1. Lighthouse report дає 100 баллів. Можливо вони були би кращими прикладами.
www.lflegal.com
www.a11yportal.com

Результат аудита
www.w3.org/...​ion?implementation_id=121
www.w3.org/...​ion?implementation_id=180

Цей сайт проходив аудит по версії 2.0 у жовтні 2013. Не думаю, що сайт змінився з 2013 року, але, звісно, зараз можуть бути додаткові проблеми. Сайт приведений лише як візуальний приклад обмежень які з’являются з рівнем ААА.
Також ця компанія займається наданням послуг для людей з порушеннямин зору в Австралії. Тому їм було потрібно пройти ААА аудит.
www.w3.org/...​entation_id=25#evaluation

Дякую.
Ми опрацювали кожен пункт стандарту для того, щоб зрозуміти що саме необхідно тестувати та розробили декілька чеклістів, що допомагають нам у тестуванні.
Наведу приклад процесу який ми використовуємо на моєму проекті.
Є декілька моментів:
1. Декілька років тому, коли ми тільки почали займатися доступністю, нам необхідно було зробити первинний аудит. Тоді ми почали вивчати стандарт та створювати чеклісти по ньому. Провели аудит та виправили більшість проблем.
Так як я писав вище, що це не одноразова робота, то далі ми змінили частину процесу для включення тестування доступності до загального складу тестування.
2. Тепер вимоги до доступності є частиною аналізу будь-яких вимог. Частина проблем вирішується ще перед початком розробки функціональності
3. Тестування доступності є частиною тестування кожної функціональності.
4. Десь кожні 6-9 місяців ми витрачаємо час на додатковий повний аудит.
Стосовно самого процесу аудиту. Ми ділимо сайт на типи сторінок і тестуємо кожний тип сторінки по всім пунктам стандарту.

Стосовно скрін рідерів. Переважно використовуємо NVDA, тому що він є одним з популярних рідерів згідно звіту (webaim.org/...​ects/screenreadersurvey8) WebAim 2019 року. Не рекомендую використовувати плагін ChromeVox тому що він читає тільки на рівні браузеру, в той час як NVDA читає на рівні системи.
З мобільних ми частіше всього використовуємо VoiceOver. Більшість проблем з доступністю є загальною як для мобільних так і для десктопа. На мобільних ми переважно тестуємо функіональність яка є унікальною для мобільних, наприклад бургер-меню.