Keyboard and focus
Core journeys are reviewed for keyboard operation, logical focus order, visible focus, and escape from interactive components.
Loading...
Our own accessibility
How Accessibility.build works toward an accessible website, how compatibility is approached, and how to get help or report a barrier.
Last reviewed: July 13, 2026
Current position
We design and test toward WCAG 2.2 Level AA. We are not currently making a formal, site-wide conformance claim or claiming independent certification.
Accessibility.build is committed to making its content, tools, account journeys, and support channels usable by people with disabilities. Accessibility is considered during design, implementation, review, and maintenance rather than treated only as a final check.
Material barriers are prioritized according to user impact. When an immediate technical fix is not practical, we will work to provide the information or service through a reasonable accessible alternative.
Coverage and boundaries
This statement covers the website at https://accessibility.build and the journeys Accessibility.build can directly design and maintain.
Design and evaluation
Review combines code-level practices, manual interaction checks, assistive-technology considerations, and automated testing. No single method can establish full WCAG conformance.
Core journeys are reviewed for keyboard operation, logical focus order, visible focus, and escape from interactive components.
Layouts are checked at narrow widths and increased zoom so content and controls remain readable without two-dimensional scrolling.
Headings, landmarks, names, states, instructions, errors, and dynamic updates are reviewed with native semantics and screen-reader behavior in mind.
Axe-based smoke tests help catch repeatable critical and serious problems. Results are reviewed because automation cannot determine full conformance.
Additional checks include color contrast, text spacing, motion preferences, labels, instructions, error handling, heading structure, landmarks, and accessible names and states. The audit methodology explains the broader professional testing process.
The site is designed for current stable versions of Chrome, Edge, Firefox, and Safari and for common keyboard, screen-reader, zoom, and voice-input use. Results can vary by operating system, browser, assistive technology, extension, and user setting.
Accessibility depends on modern HTML, CSS, JavaScript, and WAI-ARIA support. Core information should remain structured and understandable, while some interactive tools require JavaScript to perform their intended function.
Feedback and assistance
Tell us what you were trying to do, the page or tool involved, what happened, and the browser or assistive technology used. You can also request information in an alternative format or ask for help completing a task.
Do not include passwords, payment-card details, or confidential customer information. We aim to acknowledge accessibility feedback within two business days. Resolution time depends on impact, complexity, and third-party involvement.
If your report is not acknowledged within two business days, resend it with “Accessibility escalation” in the subject line.
This review clarified the formal status, covered scope, testing approach, compatibility information, feedback route, and escalation process. The statement is reviewed after material website or service changes and when reported barriers show that it is incomplete or inaccurate.
Accessibility.build is owned and operated by Khushwant Parihar in Bengaluru, Karnataka, India. See the Trust Centre, Privacy Policy, and Corrections Policy for related accountability information.