Accessibility Statement

Version 1.1 — effective August 23, 2026. All humanizes policies.

In plain language

We target WCAG 2.2 level AA across the website and the Service.
An internal audit found contrast, accessible-name, focus, heading and status-announcement defects; every one of those findings is closed and guarded by automated regression tests.
No third-party audit, conformance certification or full manual screen-reader pass has been completed, so we do not claim full conformance.
You can ask support for help or an alternative format, and you may escalate if our response does not resolve the problem.

1. Our commitment
2. Conformance status
3. What we have done
4. What the audit found, and where each finding stands
5. How we assess accessibility
6. Compatibility and known limitations
7. Technical specification
8. Alternative formats and help completing a task
9. Feedback
10. Escalation and enforcement
11. Preparation, review and contact details

1. Our commitment

humanizes, the operator of humanizes.com wants the humanizes website and Service to be usable by as many people as reasonably possible, including people who use keyboards, screen readers, magnification, voice input or other assistive technologies. Accessibility is part of our product work, not a claim that every barrier has already been removed.

We use the Web Content Accessibility Guidelines (WCAG) and the web requirements reflected in EN 301 549 as practical references for design, development, testing and remediation.

2. Conformance status

Working to WCAG 2.2 level AA — full conformance not claimed
Our target is WCAG 2.2 level AA. The accessibility defects our internal audit identified — contrast, accessible-name, focus-management, heading-structure and status-announcement failures — have been corrected, and automated tests now fail our build if any of them return.
We do not claim full WCAG 2.2 AA or EN 301 549 conformance. A full manual evaluation with assistive technology and an independent audit have not been carried out, so our honest status remains partially conformant: we have closed every defect we found, and we have not finished looking.

3. What we have done

Use semantic landmarks and headings to give pages a meaningful structure, with exactly one top-level heading per page and no skipped heading levels.
Make principal controls operable by keyboard, including the mobile navigation overlay, and provide visible focus indication.
Provide a skip-to-content link as the first focusable element on every layout.
Associate labels with form controls, mark required fields, and give icon-only buttons accessible names.
Announce humanizer progress — start, refinement and completion — through a polite status region, while keeping the rapidly changing streamed output out of live regions.
Hold text contrast to at least the WCAG AA ratio, including the small legal and disclosure text in the footer.
Respect reduced-motion preferences where animation is used, and use a responsive layout intended to reflow across viewport sizes and zoom levels.

These measures improve access, but they are the floor rather than proof of universal usability. The limits of our assessment are stated below.

4. What the audit found, and where each finding stands

Our internal audit examined the writing, humanizer, writing-style, API-key, document-upload and account flows, the marketing and legal pages, and both layout shells. It found the following categories of defect:

Audit findings and their current status
Category	What the audit found	Status
Colour contrast	Footer legal and AI-disclosure text rendered in muted colour at reduced opacity at extra-small size — the least readable text on the site.	Closed — contrast is held to the AA ratio by a deterministic test that fails the build on regression
Accessible names	Form controls in the writer, writing-style, API-key and document-upload flows, and an icon-only copy button, had missing or unclear accessible names.	Closed — controls are labelled and required fields marked, guarded by automated tests
Dynamic status updates	The streaming humanizer output and its loading states were never announced to screen readers.	Closed — progress is announced politely and the streamed output is kept out of live regions
Keyboard operability	The mobile navigation overlay was operable by mouse only.	Closed — it opens, dismisses and returns focus by keyboard, guarded by an automated test
Heading structure	Several pages had no top-level heading, and one landing page rendered a second-level heading first.	Closed — every page has one top-level heading and ordered levels, checked on rendered pages
Skip navigation	No skip-to-content link existed, so keyboard users tabbed through the navigation on every page.	Closed — every layout shell ships a skip link wired to its main landmark

“Closed” means the specific failure found in the audit has been corrected and an automated test now fails our build if it returns. It does not mean every possible barrier is removed: automated checks cannot judge, for example, whether link text makes sense out of context, whether an interaction is easy to understand, or whether an announcement is worded helpfully. If you meet a barrier we have not found, please tell us — the reporting route is below.

5. How we assess accessibility

The Service was last assessed in August 2026 through an internal combination of manual review and automated testing. The manual work exercised keyboard-only navigation, page structure and accessible names, contrast measurement, and dynamic interactions. The automated work now runs on every test pass: an axe-based check over the audited flows and pages, held to the rule list the audit's findings map to, plus a deterministic contrast check computed from the real design tokens.

The assistive technology exercised directly was keyboard-only operation and inspection of the accessibility tree in current browsers. We have not yet completed a full manual pass with screen readers such as NVDA, JAWS or VoiceOver, and we say so rather than imply it.

No independent certification
We have not commissioned a third-party accessibility audit and do not hold an Accessibility Conformance Report or VPAT. This statement is a self-assessment and is not a certification of compliance.

6. Compatibility and known limitations

The Service is designed for recent versions of Chrome, Edge, Firefox and Safari, used with current operating-system accessibility settings and recent versions of major screen readers. Older browsers, unsupported browser versions, unusual browser and assistive-technology combinations, or disabled style sheets may provide a less reliable experience.

Compatibility has not been exhaustively tested across every browser, operating system, screen reader, magnifier, voice-control tool or mobile assistive technology. Because a full manual screen-reader pass has not been completed, barriers that automated checks cannot detect may remain, particularly in dynamic interactions.

7. Technical specification

Accessibility relies on HTML, CSS, JavaScript and ARIA, together with the browser and any assistive technology in use. We prefer native HTML semantics and use ARIA where additional programme-readable information is needed.

JavaScript is required for the interactive workspace, including authentication, forms and generated results. Informational and legal pages are served as static HTML and remain available without JavaScript. Some visual enhancement or client-side navigation may be absent when JavaScript is disabled.

8. Alternative formats and help completing a task

If a barrier prevents you reading content or completing a task, ask us for the content in another reasonably available format or for help completing the task. Email support@humanizes.com and describe what you need. We will acknowledge or respond within 30 days. A complex accommodation may take longer to provide, but we will explain the next step rather than leave the request unanswered.

Possible assistance depends on the content and task. It may include providing the relevant information in accessible plain text, explaining a control, or helping with an account or billing step. We will not ask you to disclose a diagnosis or more disability information than is reasonably needed to understand the barrier.

9. Feedback

Report an accessibility problem to support@humanizes.com. To help us reproduce it, include the page address or feature, what you were trying to do, what happened, and, if you are comfortable sharing it, your browser, device and assistive technology. Do not include passwords, payment-card data or sensitive content.

We will acknowledge or respond to accessibility feedback within 30 days. Where a fix cannot be immediate, we will aim to explain the available workaround and how the issue is being handled.

10. Escalation and enforcement

If you are dissatisfied with our response, first ask for the matter to be escalated by emailing jakemorris@humanizes.com and referring to your earlier accessibility report.

Depending on where you live and which accessibility law applies, a person in the EU, United Kingdom, United States or Australia may also complain to or seek guidance from the relevant national or local equality, disability, consumer, digital-services or civil-rights body. Available routes and remedies differ by jurisdiction; this statement does not limit any statutory right.

11. Preparation, review and contact details

Prepared: 23 August 2026
Last reviewed: 23 August 2026
Last assessment: August 2026 — internal audit, remediation of every finding, and automated regression tests added to the test suite
Website: https://humanizes.com
Accessibility support: support@humanizes.com

Version history

v1.1 — August 23, 2026: Updated the conformance status after the audit's findings were remediated and automated regression tests were added; those defects are no longer listed as open, and the limits of what has been assessed are stated plainly.
v1.0 — August 23, 2026: First version establishing the accessibility target, partial-conformance status, known limitations, assessment method, accommodations and feedback process.