Accessibility Statement

Our commitment

Desert Desk is a support tool. If it isn't usable by everyone who needs support, it isn't doing its job.

That applies twice over: our customers' staff need to operate the admin portal, and their end users need to be able to ask for help through the widget. The second group didn't choose our software and often can't work around it, which makes the widget the part we hold to the higher standard.

We commit to treating accessibility defects as bugs, to publishing what we know is broken rather than only what works, and to keeping this page honest as the product changes.

Conformance status

Our target is Web Content Accessibility Guidelines (WCAG) 2.1 Level AA.

Our honest assessment is partially conformant: much of the product meets the standard, but some parts do not, and the parts we haven't tested we simply don't know about. Section 4 lists the failures we're aware of. It is not a complete list of the failures that exist — an audit would find more, which is exactly why one is on the roadmap.

What we've built

Deliberate accessibility work already in the product:

• Semantic markup and landmarks throughout the admin portal and widget, so assistive technology can identify regions and headings rather than reading an undifferentiated wall of content.
• Keyboard operation of core flows — the widget's chat composer, send, close, and menu controls are reachable and operable without a mouse, and the admin portal's forms and navigation follow standard tab order.
• Visible focus indicators on interactive elements, including on these policy pages.
• Skip-to-content links so keyboard users aren't forced through the navigation on every page.
• Reduced-motion support. Every animation in the widget and the admin portal is disabled when the operating system's “reduce motion” preference is set. This is honoured globally rather than case by case.
• Automatic text-contrast selection. Where a customer picks a background colour, the product calculates perceived brightness and chooses black or white text so the result stays legible regardless of what colour was chosen.
• Responsive layouts that reflow rather than requiring horizontal scrolling, with wide data tables given their own scroll containers so they don't break the page.
• Descriptive labels on icon-only controls, provided as accessible names rather than visual tooltips alone.
• Voice input in the chat widget for users who find typing difficult, where the browser supports it.
• No time limits on composing a message. Conversations don't expire while someone is mid-sentence.

Known gaps

Problems we're aware of. Publishing this list is uncomfortable, and it's the most useful thing on the page.

Confirmed defects

• Tooltip touch targets are too small. The contextual help icon renders at 18–22 pixels, below the 44×44 pixel minimum recommended for touch. On a phone it's fiddly for anyone without precise motor control. Not fixed
• The admin sidebar expands on hover. On desktop, the collapsed navigation rail widens to show labels when the pointer is over it. Hover-dependent disclosure is a barrier for keyboard-only and some assistive-technology users, and the pin control that solves it isn't discoverable without first seeing the expanded state. Not fixed
• Dashboard charts have no text alternative. Satisfaction and response-time visualisations are rendered to canvas with no accessible summary. The underlying figures exist on the page in some cases but are not programmatically associated with the chart. Not fixed
• Some status is conveyed by colour alone. Colour-coded chips indicate health and state in several admin views. Most carry a text label as well, but not all, and we have not verified every instance. Partially addressed
• Live-region announcements are inconsistent. Incoming chat messages, agent-typing indicators, and queue-status changes update the page dynamically. We have not systematically verified that each is announced to screen reader users at the right time and with the right politeness level. Unverified

Untested areas

• Screen reader compatibility has not been tested end-to-end with NVDA, JAWS, or VoiceOver. We have followed the practices that generally produce good results, which is not the same as knowing they did.
• Colour contrast has not been measured across every combination. Our default palette was chosen with contrast in mind, but customers can override colours in both the widget and the admin portal, and nothing currently stops them choosing a combination that fails.
• Co-browsing is inherently visual and we have not evaluated what it offers a non-sighted participant.
• Zoom and text resizing beyond 200% has not been systematically checked.
• Uploaded knowledge base documents are processed for their text content. If a customer uploads an inaccessible PDF, we extract what we can, but we do not repair the source document.

The chat widget

The widget appears on other companies' websites, which makes it the piece where an accessibility failure is least avoidable for the person affected — they came for help and can't get it.

It is built to be keyboard-operable, to expose an accessible name on every control, to honour reduced-motion preferences, and to place no time limit on composing a message. Rendering happens inside an isolated shadow root in some surfaces, which prevents host-page styles breaking our layout, though it also means the host site's own accessibility overlays may not apply to our content.

Where a customer has enabled transfers, a person can ask for a human at any point. We consider that the single most important accessibility feature in the product: if the automated path doesn't work for someone, there is a route to a person who can adapt.

If you're a customer

Embedding our widget makes its accessibility part of your website's accessibility, and any obligation you have — under the Americans with Disabilities Act, Section 508, or equivalent law where you operate — extends to it.

Things within your control that materially affect it:

• Colour choices. Check contrast when you customise the widget or portal. Nothing currently stops you choosing a combination that fails.
• Whether transfers are enabled. A route to a human is the most robust accommodation available. Turning it off removes it.
• Knowledge base quality. Clear, well-structured source documents produce clearer answers, which helps everyone and helps users with cognitive disabilities most.
• Business hours and messaging. Make sure your after-hours message tells people what to do instead, rather than leaving them at a dead end.

If you need an Accessibility Conformance Report or VPAT for procurement, we don't have one yet. Email us and we'll tell you honestly where things stand rather than filling out a form optimistically.

Assistive technology

Desert Desk is designed to work with current versions of mainstream browsers and the assistive technology built into or commonly used with them. We test primarily on recent versions of Chrome, Safari, Firefox, and Edge.

We have not verified compatibility with specific screen readers, switch access, voice control software, or braille displays. If you use one and it doesn't work, that is genuinely useful information and we'd like to hear it.

Feedback and requests

If you encounter a barrier, email support@desertdesk.app with “Accessibility” in the subject line. Helpful detail includes the page or feature, what you were trying to do, what happened, and the browser and assistive technology you were using — but please report it even if you can't supply all that.

We aim to acknowledge accessibility reports within one business day and to tell you what we intend to do, including if the answer is that a fix will take time. We treat accessibility barriers as defects, not enhancement requests.

If you need something urgently and a workaround exists, say so and we'll prioritise getting you moving over getting the fix perfect.

What happens next

In rough priority order:

1. Add contrast validation to the colour pickers, so a customer can't unknowingly configure an inaccessible widget for their own users.
2. Fix the confirmed defects in section 4 — touch target sizing, hover-dependent navigation, chart text alternatives.
3. Audit live-region announcements across the widget and helpdesk.
4. Conduct structured screen reader testing.
5. Commission a third-party WCAG 2.1 AA audit and publish the result, including whatever it finds.

We are not committing to dates. A small team promising an audit by a specific quarter is making a claim it may not keep, and this page's value depends on everything on it being true. Our Trust Center tracks this alongside our other outstanding work.

Contact

This statement was prepared on 30 July 2026 using a self-evaluation of the Desert Desk platform, and describes the product as it stood on that date.