Назвала всі 17 піктограм для зчитувачів екрана

Ситуація. Інтерфейс використовував для елементів керування системні символи, а символ без мітки доступності програма зчитування з екрана озвучує його внутрішньою назвою. Кнопку надсилання озвучувало як «стрілка вгору коло, кнопка». Так само, кожен по‑своєму, озвучувалися всі інші елементи керування із самою лише піктограмою в застосунку: сімнадцять елементів описували власне зображення, а не свою функцію.

Завдання. Кожному елементу керування із самою лише піктограмою потрібна була мітка з описом того, що він робить, а виправлення мало супроводжуватися перевіркою, бо інакше наступна ж додана піктограма одразу повернула б дефект.

Дія. Кожен із сімнадцяти елементів отримав мітку, яка називає дію, а не форму, а там, де значення елемента залежить від стану, мітка змінюється разом зі станом, а не лишається незмінною. Варто описати саме перевірку, бо загального правила «чи це доступно» для такого випадку не існує. Лінтер шукає конструкцію, яка створює елемент керування із самою лише піктограмою, і вимагає, щоб мітка доступності була не далі ніж за вісім рядків від неї. Вісім рядків — навмисно груба евристика, і це число обрали на основі вимірювань: цього достатньо, щоб охопити всі коректні способи, якими в кодовій базі записують такі елементи разом із модифікаторами, і досить мало, щоб мітка, прикріплена до іншого представлення (view) нижче, випадково не задовольнила правило. Точне правило мало б розуміти ланцюжки модифікаторів SwiftUI як дерево, а дешеве правило близькості ловить ту помилку, яка трапляється насправді: елемент не підписаний неправильно, а не підписаний зовсім.

Результат. Усі сімнадцять елементів керування озвучують свою функцію, а вісімнадцятий не можна додати без мітки. Неточність правила реальна, і про неї сказано там, де правило визначено: його може задовольнити мітка на сусідньому представленні, тож воно доводить, що мітка є поруч, але не доводить, що вона правильна, і щоб перевірити правильність, досі потрібно, щоб хтось її прослухав.