Usable by everyone
who has to use it.

DenwaysHR is used by whole workforces, not by a self-selecting group of enthusiasts. A warehouse supervisor checks a roster on a phone in bright sunlight, a finance manager runs payroll on a laptop with the display scaled up, and an employee submits a leave request using a screen reader. All three have to be able to finish the task.

So we treat accessibility as part of whether a feature is done, rather than as a remediation project that happens after launch. That is a working practice, not a claim of perfection, and this page is written to tell you honestly where we are.

This statement covers the DenwaysHR marketing website and the web application. The mobile and desktop applications are covered by the same intent but have had less dedicated testing, and we say so below.

We build against the Web Content Accessibility Guidelines version 2.2 at level AA. That is the standard most procurement processes ask about, and it is the one our internal reviews are written against.

WCAG 2.2 adds criteria that matter for a product like ours: focus that is not obscured by sticky headers, targets large enough to hit reliably on a phone, and avoiding cognitive tests such as remembering a code across steps. Those are exactly the situations an attendance or payroll flow puts people in.

Working toward a standard is not the same as being certified against it. We hold no accessibility accreditation and no third-party conformance certificate, and we will not imply one. Where a formal audit would normally be named here, there is not yet one to name.

DenwaysHR is partially conformant with WCAG 2.2 level AA. Partially conformant means most of the product meets the standard, and some parts do not yet.

We use that term deliberately. Claiming full conformance would require a completed audit of every screen and every state, including the parts of the product that are still changing week to week. We have not done that, so we do not claim it.

The sections below set out what has been done and what has not, so you can judge the gap yourself rather than take a single word for it.

The following are in place across the marketing site and the main application flows, and are checked as part of ordinary review rather than being one-off fixes.

These are the areas we know fall short. Listing them is more useful to you than a statement that says everything is fine.

Automated checks catch the mechanical failures: missing labels, contrast below threshold, images without alternative text, broken heading order. They run as part of development, and they are necessary rather than sufficient. Automated tooling finds a minority of real barriers.

Manual testing covers what tooling cannot judge. That means completing core tasks using only the keyboard, checking that focus never disappears behind a sticky element, resizing text to 200 per cent, and using the product at 400 per cent zoom to confirm content reflows into a single column.

Assistive technology testing has been carried out with screen readers on desktop and mobile, principally VoiceOver on macOS and iOS and NVDA on Windows. Coverage is real but not exhaustive, and we have not tested with every combination of screen reader and browser in common use.

We have not commissioned an independent external audit. When we do, we will publish what it found rather than only that it happened.

The application is designed for current versions of Chrome, Edge, Safari and Firefox, and for the assistive technology those browsers support. Older browsers may work but are not tested.

JavaScript is required. There is no non-scripted fallback for the application, and building one is not on the roadmap.

The interface is designed to remain usable at 200 per cent text size and at 400 per cent zoom, and to work in the operating system's high contrast and dark modes.

If something in DenwaysHR stops you completing a task, tell us. A report from someone who actually hit the problem is worth more than another internal review pass.

Send it to info@denways.com with accessibility in the subject line. Include the page or screen, what you were trying to do, what happened instead, and the browser and assistive technology you were using. A short screen recording helps but is never required.

We aim to acknowledge an accessibility report within two business days and to come back with an assessment and a plan within ten business days. If a fix will take longer than that, we will tell you how we can get you through the task in the meantime rather than leaving you waiting for a release.

We treat an accessibility barrier as a defect, not a feature request, and it is prioritised accordingly.

Where a part of the product is not yet usable for you, we will find another route to the same outcome. That may mean a data export in an accessible format, a supported walkthrough, or our team performing the step while the fix is built.

Ask through your account administrator or directly at info@denways.com. We would rather you get the task done than wait for a release cycle.

This statement is reviewed at least every twelve months, and again whenever a significant part of the interface changes. The date at the top reflects the current version.

Each review re-checks the known limitations list, removes what has been fixed, and adds anything new that has been found. A limitation disappearing from this page means it was fixed, not that we stopped mentioning it.

Accessibility feedback received between reviews feeds directly into the backlog rather than waiting for the next cycle.

Accessibility questions and barrier reports go to info@denways.com. Procurement questions about our conformance position, including requests for a completed accessibility conformance report, go to info@denways.com.

If you are an employee of a company that uses DenwaysHR, you can contact us directly about an accessibility barrier. You do not need to route it through your employer first.