Accessibility statement

Our accessibility commitment

HireHint is intended to support recruiting, employee operations, and people decisions for people with different access needs, devices, input methods, and viewing conditions.

Accessibility is treated as a product-quality requirement across public pages, authenticated workspaces, protected routes, dialogs, tables, forms, loading states, and error recovery. This statement describes the current engineering approach without claiming an independent certification.

Scope

• HireHint public, authentication, recruiting, candidate, employee, settings, reporting, and administration interfaces.
• Customer-configured careers, application, privacy-request, survey, interview, and assessment experiences provided by HireHint.
• Responsive behavior at supported desktop, tablet, phone, landscape, and constrained-height viewports.
• Generated documents, customer content, customer-selected integrations, and third-party destinations only to the extent HireHint controls their rendering.

Structure and navigation

• Semantic page landmarks, headings, navigation labels, lists, tables, forms, status messages, and dialog relationships.
• A visible keyboard focus treatment and logical focus order for supported controls.
• Skip links or equivalent direct access to primary content on public-document pages.
• Route and permission behavior that prevents protected content from appearing before access is resolved.
• Names and relationships for icon-only, provider, disclosure, menu, and overlay controls.

Keyboard and focus behavior

HireHint components are designed to support keyboard navigation without requiring a pointer. Modal dialogs and other blocking overlays should contain focus, support an appropriate Escape behavior, isolate background content, and restore focus to the initiating control when closed.

Menus, tabs, listboxes, disclosures, tables, and composite controls use component-specific keyboard behavior. An unavailable action should be disabled or explained without creating a misleading focus target.

Forms, validation, and status

• Labels and instructions remain programmatically associated with their fields.
• Required, invalid, disabled, loading, checked, and password-visible states are distinguishable without relying only on color.
• Validation messages identify the affected field and preserve entered information when recovery is possible.
• Loading, success, warning, empty, and error states use appropriate status or alert semantics without unnecessary repeated announcements.

Responsive and visual access

Layouts are designed to reflow without hiding required controls or protected-state information at supported viewport sizes. Tables, cards, pipelines, drawers, navigation, sticky regions, and nested scrolling receive route-specific containment checks.

HireHint supports user preferences for reduced motion and high-contrast or forced-color presentation where the browser exposes them. Color, motion, position, or icon shape should not be the only way to communicate a required state.

Customer and third-party content

Customers control job descriptions, careers content, uploaded documents, form questions, messages, videos, and some connected services. Customers are responsible for making that content understandable and accessible and for providing an alternative when a selected third party cannot meet the required need.

HireHint should not represent customer-authored or third-party content as independently verified merely because it is displayed through the service.

Testing and current boundaries

HireHint uses source contracts, component tests, browser interaction tests, responsive checks, build gates, and visual regression checks as part of accessibility engineering. Those controls do not replace testing with people who use assistive technologies.

No current statement of full conformance with a named accessibility standard or independent audit is made here. Native browser zoom, multiple screen-reader and browser combinations, voice input, switch control, and customer-configured third-party content require additional release-specific evidence.

Accessibility feedback and support

Use HireHint Support to report an accessibility barrier, request information in another format, or ask for help completing a supported task. Include the page or workflow, the problem encountered, the browser or assistive technology if relevant, and a safe way to follow up.

Do not include passwords, authentication codes, candidate records, employee records, medical details, or other unnecessary sensitive information in the initial report.

Review and updates

This statement should be reviewed after material interface, component-library, accessibility-test, or supported-technology changes. Confirmed barriers should be prioritized by impact, reach, affected workflow, available workaround, and risk to protected information.