Can the path be completed by keyboard?
Preparing the governed record.
Bookwiser is loading the requested public or applicant surface without changing its authority state.
Accessible operating pathsTrust and support
The operating path must remain usable without perfect vision, hearing, movement, memory, or input precision.
Bookwiser targets WCAG 2.2 AA across primary public, beta, account, and workspace journeys. Current engineering includes semantic structure, visible focus, reduced motion, contrast controls, keyboard paths, responsive reflow, and explicit errors. The R64 source and automated accessibility audit is complete, while hands-on assistive-technology verification remains required before any conformance claim.
Begin with the decisions people actually need to make.
These questions connect the public notice to real work, real responsibilities, and a clear next step instead of leaving it as abstract policy language.
Does content reflow at zoom and narrow widths?
Are errors and states announced?
Is an alternate support path available?
Purpose, responsibility, supporting records, and limits stay visible.
The register explains what Bookwiser manages, what requires another person or provider, and which decisions remain outside this process.
Logical focus, Escape, visible focus, semantic controls
Pointer-only interaction is not accepted for primary journeys.
Contrast, zoom, reflow, labels, text alternatives
Information must not depend on colour or tiny text.
Reduced-motion support and no scroll hijacking
Essential content remains available without animation.
Labels, instructions, validation, status messages
A person should know what changed and how to recover.
Four stages, with a history that survives the handoff.
This is the expected path through Bookwiser. Actual service, account, provider, privacy, and legal obligations continue to follow the agreements and policies accepted for that relationship.
Report the barrier
The user names the route, task, device, assistive technology, and observed barrier when available.
Assess severity and path
The team identifies whether the barrier blocks access, creates serious friction, or has a practical workaround.
Remediate and verify
The fix is tested against the affected journey and relevant keyboard, screen-reader, zoom, reflow, contrast, or motion criteria.
Update the statement
Material limitations, fixes, audit results, and contact paths are reflected in the public record.
Every promise needs an owner and a way to check it.
These are Bookwiser's public commitments. Signed agreements, qualified professional opinions, and customer-specific deployment reviews add the terms required for each actual relationship.
No accessibility penalty
Accessibility needs are optional in beta qualification and must not reduce an applicant score.
Alternate route
When a digital path is blocked, the support process should provide a reasonable alternate method.
Evidence before conformance
Automated checks, manual review, assistive technology, and representative journeys all contribute to the audit.
Public remediation record
Material accessibility findings and resolution status should remain visible and current.
Where responsibility remains elsewhere
A public page should never quietly give Bookwiser more authority than the relationship does.
- Unverified conformance claim
- Pointer-only primary actions
- Colour-only status
- Accessibility needs used in admissions scoring
Choose the route that can keep the right context with the right team.
For your protection, do not send passwords, credentials, tax identifiers, unredacted legal files, private customer records, or complete banking documents through a public contact path.
Report a barrierUse contact routing and choose accessibility so the task and required alternate path are retained.Report accessibility Get account helpUse the support map to choose the account, privacy, security, or accessibility path that retains the needed context.Open support Review the support mapChoose the correct public, applicant, account, or security route.Review support