1. Our commitment
Smileline is used all day by reception teams, and it has to work for everyone on them. We aim for the web app, the Desk desktop app, the browser extension and the mobile app to meet WCAG 2.2 level AA. Every screen is built to be usable with a keyboard alone, with a screen reader, at 200% zoom, and with the system's reduced-motion and high-contrast settings.
2. What we do
- Every control has a name a screen reader can announce, including the softphone's mute, hold, keypad, transfer and end-call buttons.
- Incoming calls are announced visually, audibly and, when the tab is hidden, through the browser's notification — never by colour alone.
- Live regions announce state changes such as a call being put on hold or a message failing to send.
- Colour is never the only carrier of meaning; text sizes follow the browser's settings.
- Accessibility checks run on every change in our automated tests.
3. What is not yet right
- Some drag-and-drop pipeline interactions have a keyboard alternative that is slower than the pointer route.
- The call-recording player's waveform is decorative and has no textual timeline yet; the transcript beside it is the accessible route.
- The Desk app's tray menu follows the operating system's own accessibility support, which varies by platform.
We are working through these and will update this list as each is fixed.
4. Tell us
If something in Smileline is hard or impossible for you to use, email support@smileline.io or use Help → Contact support in the app. We treat accessibility reports as defects, not feature requests, and we reply within two business days. If you are not satisfied with our response, our Complaints code applies.
5. Enforcement and standards
In the United Kingdom the Equality and Human Rights Commission enforces the Equality Act 2010; in the United States the Americans with Disabilities Act and Section 508 set the standard our customers may be held to. This statement was prepared against WCAG 2.2 and is reviewed when the product changes materially.