Accessibility

Conformance status

VuseDesk is partially conformant with WCAG 2.2 Level AA. "Partially conformant" is the standard's own term, and it is the honest one: most of the product meets the standard, and the parts that do not are named further down this page rather than left for you to discover.

We have not claimed full conformance, and we will not until the items under Known limitations are closed and an evaluator who did not build the software has checked our work. We would rather be accurate than impressive.

Statement prepared 29 September 2026. Based on an evaluation carried out on 29 September 2026 against WCAG 2.2 Level AA.

What this statement covers

This statement applies to the public website at www.vusedesk.com, the signed-in contractor application, and the client, subcontractor and employee portals.

It does not cover two things, and both are worth naming. PDF documents produced by the platform, such as a signed contract or an invoice, are not yet tagged for screen readers. And content you put into the product yourself, such as a photograph you upload or a document you write, is yours: whether it is accessible to your own client depends on what you provide. Where the product can help you with that, it should, and where it does not yet, that is our gap and not yours.

How we evaluated, and what that is worth

An accessibility statement is only as good as the testing behind it, so here is exactly what was done and what it does and does not prove.

What we did

• Direct measurement in a real browser, on 29 September 2026. Every text element on the pages tested was measured for its actual computed contrast ratio against its actual composited background, at its real rendered font size and weight, and checked against the ratio WCAG requires for that size. This was not a visual judgement and not a spot check of the colour palette.
• Structural checks in the same pass: heading order, landmark regions, accessible names on every link, button and form control, images missing alternative text, language declaration, whether page zoom is blocked, whether any clickable element is unreachable by keyboard, target sizes against the 24 by 24 pixel minimum, and horizontal overflow at phone width.
• A detailed code review of all five portals, carried out in August 2026, which read every screen's markup and stylesheet and produced a written list of barriers. Several fixes in the product came directly from it, including the keyboard alternative on the signature pad described below.
• Layout testing at 375 pixels wide, confirming no horizontal scrolling and no content pushed off screen.

What we found, and fixed the same day

Naming what was wrong is part of the evidence that the testing was real.

• Footer section headings were marked up as fourth-level headings on pages whose content stopped at the second level, which made every page skip a heading level. Corrected across the whole site.
• Eight pages had no main landmark region, so a screen reader user had no single "skip to the content" destination. Added.
• The consent checkboxes on the signup sheet were 20 by 20 pixels, below the 24 by 24 minimum WCAG 2.2 introduced. Enlarged. These are the controls that record a legal agreement, so they were the least acceptable place to be under the minimum.

What we measured after fixing

• Contrast: no failures. Across the home, pricing, policies and signup pages, 276 text elements were measured against their real backgrounds and every one met the required ratio. A further 67 elements sit on gradients or photographs, where a single ratio cannot be computed honestly; those are flagged for manual review rather than counted as passes.
• No missing alternative text on any image.
• No link, button or form control without an accessible name.
• No heading level skips.
• No element with a click handler that a keyboard cannot reach.
• Zoom is not blocked. No page prevents pinch-zoom or caps the scale, so text can be enlarged to 200 percent and beyond.
• No horizontal overflow at 375 pixels.

What this does not prove

This is the part most accessibility statements leave out, so we will be plain about it.

• We have not tested with screen readers in use. No part of this evaluation involved operating the product with JAWS, NVDA, VoiceOver or TalkBack. Automated measurement and code review find missing labels and failing contrast; they do not tell you whether a screen reader announces a screen in an order that makes sense, or whether a live region interrupts at the wrong moment. Those are the things only real use finds.
• We have not done usability testing with disabled users. A page can pass every automated check and still be miserable to use. Anyone who tells you otherwise is selling something.
• No independent third party has audited us. Everything above was measured by the team that built the software.
• Automated testing covers a minority of the standard. Roughly a third of WCAG success criteria can be checked by a machine at all. The rest need judgement.

All three of those gaps are work we intend to do rather than positions we are defending. We will update this page, with dates, as each is closed.

What is in place

• Semantic structure. Real headings in order, landmark regions on every page, and a "skip to content" link that appears on the first press of the Tab key. The skip link is wired to the main region at runtime and removes itself rather than dead-ending your focus if a page has no target.
• Labelled forms. Every input, select and checkbox has a name a screen reader can read out. Errors are shown as text, never by colour alone.
• Keyboard operation of the main flows, with a visible focus ring. The ring colour is re-pointed per surface, because one colour cannot clear the 3 to 1 minimum against both a white page and a navy band, and the measured ratios for each surface are recorded in the stylesheet.
• A keyboard alternative to drawing a signature. Signing by drawing needs a mouse, a trackpad or a finger. Anyone who cannot use one can type their name instead, and the typed signature carries exactly the same legal weight and the same audit record. This was a barrier found in the August review and it was fixed.
• Reduced motion is honoured. If your system asks for less animation, the interface stops moving.
• Text scales. The layout is built in relative units and holds together when text is enlarged, down to a 375 pixel wide phone.
• Colour is never the only signal. Status is carried by words as well as colour, so "overdue" says overdue.

Known limitations

We would rather name these than have you find them. Each one is real, and each one has a workaround you can use today.

• Generated PDFs are not tagged. A signed contract or invoice produced by the platform is not structured for a screen reader. If you need one in an accessible format, ask us and we will provide it.
• Rich controls may not be fully operable by every assistive technology. The calendar and scheduling widgets in particular are more complex than a form field and have not been verified with a screen reader. Anything you can do in those screens, we can do for you or arrange another way.
• Some inline form errors are not announced. An error can appear as text without being wired to a live region, so a screen reader may not read it out at the moment it appears. The error is still on screen and still reachable.
• Text on photographs and gradients has not been contrast-verified. 67 elements sit on backgrounds where a single ratio cannot be computed, mostly headlines on the marketing pages. They have not been shown to fail; they have not been shown to pass either.
• The signed-in application has had less measurement than the public site. The evaluation above covered the marketing and signup pages directly. The application screens were covered by the August code review rather than by browser measurement.

If any of these stops you doing something that matters, tell us and we will get it done for you another way while we fix it. That is not a brush-off; it is a commitment, and the contact route is below.

Compatibility and requirements

VuseDesk is built with HTML, CSS and JavaScript, and relies on JavaScript being enabled. It is designed to work with current versions of Chrome, Edge, Firefox and Safari on desktop, and Chrome and Safari on phones and tablets, each with that platform's built-in assistive technology. It is not tested against browsers more than two major versions old.

We have not verified behaviour with any specific screen reader, as stated above, so we cannot list supported assistive technology honestly. When we have tested, this section will name the exact combinations and the dates.

Report a barrier, or ask for another way

If something here blocks you, we want to know, and you should never have to argue for it.

• Email [email protected] with "Accessibility" in the subject line.
• Or call (757) 782-8577 if writing is the barrier.

Tell us what you were trying to do, the page or screen, and the device and assistive technology you use, if you know it. You do not need to know the name of a standard or use any particular words.

What we commit to: we acknowledge within 2 business days, and give you a substantive answer within 10 business days. Where a fix will take longer, we say so, give you a date, and in the meantime provide the information or complete the action for you in another format at no charge. If you are not satisfied with our answer, say so and it will be looked at again by someone else.

This statement is reviewed at least once a year and whenever a significant change ships. Last reviewed and evaluated 29 September 2026.