# Named all seventeen interface icons for screen readers after finding the send button announced as "arrow up circle, button", and wrote the linter that requires the label within eight lines of the icon. 2025 **Situation.** The interface used system symbols for its controls, and a symbol with no accessibility label is read out by the screen reader as its own internal name. The send button announced as "arrow up circle, button". So did every other icon‑only control in the application, in its own way — seventeen of them describing their own artwork instead of their function. **Task.** Every icon‑only control needed a label describing what it does, and the fix had to come with a check, because the next icon added would otherwise reintroduce the defect immediately. **Action.** Each of the seventeen was given a label naming the action rather than the shape, and where the control's meaning depends on state the label follows the state instead of being fixed. The check is the part worth describing, because a general "is this accessible" rule does not exist for this. The linter looks for the construction that creates an icon‑only control and then requires an accessibility label within eight lines of it. Eight lines is a deliberately crude heuristic and it was chosen by measurement: it is long enough to span every legitimate way the codebase writes one of these controls with its modifiers, and short enough that a label attached to a different view further down does not accidentally satisfy it. A precise rule here would need to understand SwiftUI's modifier chains as a tree, and the cheap proximity rule catches the actual mistake — which is not a mislabelled control, it is an unlabelled one. **Result.** All seventeen controls announce their function, and an eighteenth cannot be added without one. The rule's imprecision is real and stated where it is defined: it can be satisfied by a label on a neighbouring view, so it proves a label exists nearby rather than proving the label is correct, and correctness still needs someone to listen to it. --- - Role: Accessibility Specialist - Categories: [Frontend Engineering](https://engineer.company/categories/frontend/), [Automation & CI/CD](https://engineer.company/categories/automation/), [Testing & QA](https://engineer.company/categories/testing/), [Design Systems & UI](https://engineer.company/categories/design-systems/), [UX / UI Design](https://engineer.company/categories/ux-ui/), [Documentation](https://engineer.company/categories/documentation/) - Services: [Frontend Development](https://engineer.company/services/frontend-development/), [UI/UX Design & Design Systems](https://engineer.company/services/ui-ux-design/)