Accessibility Statement
Last reviewed against the live site: 2026-07-29
NP Hiring (operated by Akari Labs LLC) is a job board for nurse practitioners. People use it to find work, so it has to work with a keyboard, with a screen reader, at high zoom, and with motion turned off. This page states what we have actually built, what we know is still broken, and how to tell us when something blocks you.
Conformance status: partial. We build to WCAG 2.2 Level AA as our target, and we do not claim to fully meet it. The gaps listed further down are the ones we have found and confirmed ourselves. This is a self-assessment: no independent audit has been performed, and we do not publish a VPAT. We would rather publish an honest partial statement than a conformance badge we cannot stand behind.
What works today
Each item below is a control that ships in the product right now, with the success criterion it is there to serve:
- A "Skip to main content" link is the first focusable element on every page and jumps past the header navigation. (WCAG 2.4.1 Bypass Blocks)
- Keyboard focus is always visible: a two-tone focus ring is applied globally on :focus-visible, so it appears for keyboard and switch users without adding a click outline for mouse users. (WCAG 2.4.7 Focus Visible)
- The five dialogs in the search-and-apply path — the apply modal and its confirmation, the job-alert modal, the mobile filter drawer, the employer message composer, and the report-job flow — share one focus-trap hook: focus moves into the dialog, Tab cycles inside it, Escape closes it, and focus returns to the control that opened it. Other dialogs on the site do not do this yet, and they are listed as a known gap below. (WCAG 2.1.2 No Keyboard Trap · 2.4.3 Focus Order)
- Dialogs carry role="dialog", and every one except the cookie banner also carries aria-modal. Icon-only buttons carry accessible names, and list rows that behave like buttons expose role="button" with Enter/Space handling rather than a bare click target. (WCAG 4.1.2 Name, Role, Value)
- Motion honors prefers-reduced-motion in CSS: smooth scrolling becomes instant jumps, and CSS entrance animations, scroll reveals, and the skeleton shimmer are switched off. Three of the JavaScript-animated sections — the employer how-it-works steps, the featured-jobs grid, and the top-states list — check the preference themselves and render straight to their resting state. Two other JavaScript-driven animations do not yet, and they are listed as a known gap below. (WCAG 2.3.3 Animation from Interactions)
- Form fields — including employer screening questions on the apply form — have programmatic labels, client-side validation with in-context error text, and visible character limits rather than silent server-side truncation. (WCAG 3.3.1 Error Identification · 3.3.2 Labels or Instructions)
- Blocking window.alert() has been removed from the product surfaces in favour of in-page messaging, and the removal is enforced by a test so it cannot creep back. (WCAG 2.2.1 Timing Adjustable (supporting))
Known gaps — the honest list
These are real barriers on the site today. We publish them because you deserve to know what you will run into before you run into it.
Low-contrast secondary text.
Several muted grey tokens used for metadata, helper text, and captions measure between roughly 1.9:1 and 4.2:1 against our light backgrounds — below the 4.5:1 minimum for normal-size text. Anyone with low vision, or reading on a bright screen outdoors, may lose that text.
What we are doing: We are darkening the muted text tokens site-wide. The primary body and heading colours already pass comfortably; this affects secondary copy.
Focus is not trapped in every dialog.
Five dialogs share our focus-trap hook, but the rest do not: the cookie banner, the mobile navigation menu, the shared confirm dialog, the resume-autofill review, and the three job-description starter modals. In those, Tab can walk out of the dialog into the page behind it, and closing the dialog does not return focus to the control that opened it — so a keyboard or screen-reader user loses their place. The cookie banner is also the one dialog missing aria-modal and an Escape handler.
What we are doing: We are moving the remaining dialogs onto the same shared hook. Each one that moves across leaves this list and joins the list above in the same change.
Two JavaScript-driven animations ignore reduced motion.
Our site-wide reduced-motion rule is written in CSS, and the animation library a handful of sections use drives its movement from JavaScript, where that CSS rule cannot reach it. Three of those sections check the preference themselves; the homepage hero entrance and the mobile navigation overlay do not, so they still animate for people who have asked their system for less motion.
What we are doing: Both are moving onto the same reduced-motion check the other three already use. When they do, this entry is deleted in the same change.
Status messages are not announced.
Confirmation and error toasts appear visually but are not exposed in a live region, so screen-reader users may not hear that a save, apply, or alert action succeeded.
What we are doing: Adding a polite live region to the shared toast component is the next accessibility change queued.
Some data tables lack header associations.
Several tables — including the salary-guide and pricing tables — use visually styled header rows without scope attributes or a caption, so a screen reader may not tie a cell back to its column heading.
What we are doing: We are adding scope attributes and captions table by table. The employer comparison table, the press data table, and the resource-guide tables have been corrected already.
The downloadable salary-guide PDF is not tagged.
It is produced by printing a web page to PDF, which does not emit a tagged reading order, so assistive technology may read it out of order.
What we are doing: The same content is published as accessible HTML on our salary guide, and we link there as the primary source. Ask us and we will send the content in whatever format works for you.
Employer-authored job descriptions.
Job description HTML is written by the hiring organisation. We sanitise it for safety, but we cannot guarantee its heading order, link text, or image alternatives.
What we are doing: Report a specific listing and we will contact the employer or correct the markup.
No independent audit and no automated checks in our test suite.
Everything above is a self-assessment by the team that builds the site. We have not commissioned a third-party audit, we do not publish a VPAT, and our continuous integration does not yet run automated accessibility scans.
What we are doing: Automated scanning in CI first, an external review after that. We will say so here when either lands.
Parts of the experience we do not control
- Payment. Paid job posts are completed on Stripe's hosted checkout. That page is Stripe's, not ours, and its accessibility is governed by their own statement.
- Employer application sites. Many listings send you to the employer's own application system. Where a job supports applying on NP Hiring directly, that flow is ours and the accessibility commitments on this page apply to it.
- Outbound links to boards and agencies. State board of nursing sites, federal data sources, and certification bodies are third-party sites we cite but do not operate.
Report a barrier
If any part of NP Hiring stops you from finding a job, applying, or posting a role, email contact@nphiring.com with the word "accessibility" in the subject. It helps if you can include:
- the page address where it happened;
- what you were trying to do;
- your browser, and your screen reader or other assistive technology if you use one.
We aim to acknowledge accessibility reports within five business days. If a fix will take longer than that, we will tell you what the timeline is — and in the meantime we will get you the information or complete the task with you another way, by email or phone, at no disadvantage to you.
If our response does not resolve things, you can escalate to support@nphiring.com, which reaches the same team through a monitored operational queue.
Standards and related policies
We measure ourselves against the Web Content Accessibility Guidelines 2.2 at Level AA.
- Editorial Policy — how our content and statistics are produced and sourced.
- Security & Trust — how we protect your data.
- Privacy Policy and Terms of Service.
