Accessibility statement

Last updated August 4, 2026.

Web Friendly Help LLC is committed to making ResumeHarbor accessible to as many people as possible, including people with disabilities. ResumeHarbor is an accessible, AI-assisted résumé and cover letter builder. This statement describes the accessibility of the site and how to reach us if you encounter a barrier. It reflects a self-assessment conducted during active development; the site has not yet undergone an independent third-party accessibility audit.

Conformance status

The Web Content Accessibility Guidelines (WCAG) define requirements to improve accessibility for people with disabilities, across three levels: A, AA, and AAA. Our target is WCAG version 2.2, Level AA.

ResumeHarbor is partially conformant with WCAG 2.2 Level AA, based on our own internal self-evaluation. "Partially conformant" means most of the site meets the target while some content does not yet fully conform, and that this assessment is self-reported rather than verified by an independent auditor. We are actively working toward full conformance and a formal audit.

Measures we have taken

• Semantic HTML with a clear landmark structure (header, primary navigation, main content, and footer navigation), one H1 per page, and a logical heading hierarchy.
• Full keyboard operability, with a visible two-color focus indicator that stays visible on light and dark backgrounds and over colored buttons.
• Screen reader support designed against NVDA, JAWS, and VoiceOver reading patterns, with labeled fields, in-context instructions, and focusable error summaries.
• A polite live region for status messages and a separate assertive region for errors, plus a route announcer that announces page changes and moves focus when you navigate within the app.
• A skip link to the main content and full support for the reduced-motion preference. Form controls and standard buttons are at least 44 by 44 pixels. Buttons styled to sit inline within a sentence are smaller, at 24 pixels, which is the minimum WCAG 2.2 Level AA asks for; links inside body text follow the surrounding line height, which the standard allows.
• System, light, and dark themes, plus five high-contrast color schemes: black on white, white on black, dark brown on tan, yellow on black, and ice blue on navy. Your choice is applied before the page paints, so there is no flash of the wrong colors, and the panel speaks the contrast ratio when you settle on one.
• Support for Windows High Contrast and other forced-colors modes, with a note in the appearance panel explaining that your system colors are in charge there.
• Keyboard shortcuts announced with aria-keyshortcuts and shown as visible hints: Alt+Shift+B moves focus to the file upload control, and Control+S saves in the profile, résumé, and cover letter editors.
• Leaving an editor with unsaved changes brings up an inline prompt rather than a modal, offering to save first, stay, or discard, with the discard option naming what it discards.
• Every page carries its own title, including the pages reached only by a link in an email, where a fresh page load is the only way you ever arrive and the title is the only announcement you get.
• Status messages are paced rather than fired on every keystroke, so arrowing through the color schemes or editing a résumé does not leave a queue of stale announcements playing after you have stopped.
• Native form controls rather than custom widgets, descriptive link text, and content presented as lists where a data table is not needed.
• Destructive actions such as account deletion use a type-to-confirm step with clear instructions, in line with WCAG 3.3.4 (Error Prevention).

Technical specifications and compatibility

Accessibility of ResumeHarbor relies on HTML, CSS, and JavaScript (including WAI-ARIA roles, states, and properties) working with your browser and assistive technologies. The site is designed to work with current versions of Chrome, Edge, Firefox, and Safari together with common screen readers such as NVDA, JAWS, and VoiceOver. It may not behave as intended in very old browsers that do not support these technologies.

Known limitations

Despite our efforts, some areas are not yet fully accessible or are still in progress:

• Our automated scan checks the default theme. The custom color schemes are derived from the colors you pick, so their contrast is checked by hand, and in August 2026 an outside review found that we had got it wrong: on the white-on-black scheme, the box that explains why a form failed was being drawn at roughly 1.2 to 1, which is unreadable, and it is the box we deliberately move your focus to. It is fixed, and every scheme now meets the standard, one of them only narrowly. We are telling you because it is exactly the kind of failure that hits the people who choose a high-contrast scheme because they need one, and because our own testing did not catch it.
• Moving between two views of the same page that differ only by what follows the question mark in the address does not announce. Nothing in the site does that today; it is a note for ourselves before anything does.
• The site has not had a formal independent accessibility audit, so the conformance status above is based on internal self-assessment. Our own record above is the reason we are keeping that caveat rather than dropping it.

If you find a limitation not listed here, please tell us using the feedback details below.

Assessment approach

Web Friendly Help LLC assesses accessibility by self-evaluation, carried out internally. Automated checks run on every change: an axe-core scan drives a real browser through a set of public and signed-in pages, checking against WCAG 2.0 and 2.1 at Levels A and AA plus the Level AA additions in 2.2. It reports on every proposed change and every change that ships. It is a detector rather than a gate, so a failure raises the alarm rather than physically preventing a release, and automated checking finds only the failures a machine can see.

Beyond the automated scan, the site has been through two dated review rounds with every finding tracked to closure (June 19 and June 23, 2026) and a further four-part review in August 2026 covering accessibility alongside security and correctness.

Screen reader behavior has repeatedly changed the code rather than merely being checked against it. The appearance panel uses a radio group instead of a dropdown, and deliberately leaves focus where you left it, because of how VoiceOver on iOS handles those controls; announcements are paced because of how NVDA queues them. This testing is done with NVDA and VoiceOver. We describe the site as designed against JAWS reading patterns rather than verified with JAWS, and we would rather say so than imply a test we have not run.

Feedback

We welcome your feedback on the accessibility of ResumeHarbor. If you encounter a barrier, or need information in a different format, email the accessibility team at help@resumeharbor.pro. We aim to respond promptly, and your reports help us improve the site for everyone.