# Назвала всі 17 піктограм для зчитувачів екрана Дала назви для зчитувачів екрана всім елементам керування, що складаються лише з піктограми, після того як виявила, що кнопка надсилання оголошувалася як «arrow up circle, button», і написала лінтер, який вимагає підпису в межах восьми рядків від піктограми. вересень 2026 **Ситуація.** Інтерфейс використовував для елементів керування системні символи, а символ без мітки доступності програма зчитування з екрана озвучує його внутрішньою назвою. Кнопку надсилання озвучувало як «стрілка вгору коло, кнопка». Так само, кожен по‑своєму, озвучувалися всі інші елементи керування із самою лише піктограмою в застосунку: сімнадцять елементів описували власне зображення, а не свою функцію. **Завдання.** Кожному елементу керування із самою лише піктограмою потрібна була мітка з описом того, що він робить, а виправлення мало супроводжуватися перевіркою, бо інакше наступна ж додана піктограма одразу повернула б дефект. **Дія.** Кожен із сімнадцяти елементів отримав мітку, яка називає дію, а не форму, а там, де значення елемента залежить від стану, мітка змінюється разом зі станом, а не лишається незмінною. Варто описати саме перевірку, бо загального правила «чи це доступно» для такого випадку не існує. Лінтер шукає конструкцію, яка створює елемент керування із самою лише піктограмою, і вимагає, щоб мітка доступності була не далі ніж за вісім рядків від неї. Вісім рядків — навмисно груба евристика, і це число обрали на основі вимірювань: цього достатньо, щоб охопити всі коректні способи, якими в кодовій базі записують такі елементи разом із модифікаторами, і досить мало, щоб мітка, прикріплена до іншого представлення (view) нижче, випадково не задовольнила правило. Точне правило мало б розуміти ланцюжки модифікаторів SwiftUI як дерево, а дешеве правило близькості ловить ту помилку, яка трапляється насправді: елемент не підписаний неправильно, а не підписаний зовсім. **Результат.** Усі сімнадцять елементів керування озвучують свою функцію, а вісімнадцятий не можна додати без мітки. Неточність правила реальна, і про неї сказано там, де правило визначено: його може задовольнити мітка на сусідньому представленні, тож воно доводить, що мітка є поруч, але не доводить, що вона правильна, і щоб перевірити правильність, досі потрібно, щоб хтось її прослухав. --- - Роль: Спеціаліст з доступності - Категорії: [Frontend‑розробка](https://engineer.company/uk/categories/frontend/), [Автоматизація та CI/CD](https://engineer.company/uk/categories/automation/), [Тестування та QA](https://engineer.company/uk/categories/testing/), [Дизайн‑системи та UI](https://engineer.company/uk/categories/design-systems/), [UX / UI‑дизайн](https://engineer.company/uk/categories/ux-ui/), [Документація](https://engineer.company/uk/categories/documentation/) - Послуги: [Frontend‑розробка](https://engineer.company/uk/services/frontend-development/), [UI/UX‑дизайн та дизайн‑системи](https://engineer.company/uk/services/ui-ux-design/)