Keyboard and focus
Core journeys are reviewed for keyboard operation, logical focus order, visible focus, and escape from interactive components.
Our own accessibility
Accessibility statement
How Accessibility.build works toward an accessible website, how compatibility is approached, and how to get help or report a barrier.
Last reviewed: September 2, 2026
Current position
At a glance
Accessibility.build is partially compliant with WCAG 2.2 Level AA. The site is designed and tested toward that level, and the known exceptions are listed under non-accessible content below. No independent certification is claimed.
- Technical target
- WCAG 2.2 Level AA
- Compliance status
- Partially compliant
- Assessment basis
- Internal manual and automated review
- Feedback acknowledgement
- Within two business days
Our commitment
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
What this statement covers
This statement covers the website at https://accessibility.build and the journeys Accessibility.build can directly design and maintain.
Included
- public pages, research, guides, checklists, and WCAG references;
- free and account-based accessibility tools;
- sign-in, onboarding, dashboard, billing, and profile journeys we control;
- contact, support, and professional-service enquiry routes;
- downloadable resources produced and maintained by Accessibility.build.
Partly outside our control
- hosted authentication, payment, email, analytics, and form services;
- linked third-party websites and external documents;
- user-submitted websites, images, files, code, and other content;
- browser extensions and unsupported browser or assistive-technology versions.
Non-accessible content
Known issues as of September 2, 2026. Each is either being fixed or is listed so you know what to expect.
The content listed below is not fully accessible for the reasons given. Where a WCAG 2.2 success criterion applies, it is named.
- Interactive tools require JavaScript. The contrast checker, palette and typography studios, auditors, and generators do not function with scripting disabled. Guides, references, and research remain readable without it.
- Some long code samples scroll horizontally. At a 320 CSS pixel width, code blocks in guides keep their line structure and scroll inside their own container rather than wrapping. WCAG 2.2 success criterion 1.4.10 (Reflow) permits this for code, and it is listed here for transparency.
- Procurement downloads are plain Markdown files. The sample statement of work, NDA checklist, and data-processing overview open as plain text in the browser, so their headings are not exposed as structural headings (relevant to 1.3.1, Info and Relationships). Ask for an HTML or tagged PDF copy through the feedback route.
- Third-party interfaces are reviewed, not controlled. Sign-in and account management (Clerk), checkout (Razorpay and Stripe), and the analytics consent library are supplied by vendors. Barriers found in them are reported to the vendor and, where possible, worked around.
- Not every page has had a full manual evaluation. Core journeys and templates are reviewed manually; automated axe checks run across the rest. Until every one of the more than 280 pages has been manually evaluated against all 86 criteria, the site is described as partially compliant rather than fully compliant.
How the service meets the accessibility requirements
General description of the service and its accessibility features, in the form the European Accessibility Act (Annex V) asks service providers to publish.
Description of the service. Accessibility.build is a website offering free reference content (WCAG success-criterion guides, implementation guides, compliance explainers, research, and a glossary), browser-based accessibility tools, optional accounts that hold tool credits and saved reports, and an enquiry route for professional accessibility services delivered by the founder.
Accessibility features that support the service. Pages use semantic HTML with landmarks and a logical heading outline, and every page starts with a skip link to the main content. All controls are operable by keyboard with a visible focus indicator, and dialogs, menus, and expandable sections manage focus and can be closed with Escape. Text alternatives are provided for meaningful images, and decorative graphics are hidden from assistive technology. Body text meets the 4.5:1 contrast minimum in both the light and dark themes, layouts reflow to a 320 CSS pixel width without two-dimensional scrolling for text content, and text can be resized in the browser. Form fields carry visible labels, required-field indicators, and error messages that identify the field and describe the problem. Tool results are presented as text (for example, contrast ratios and pass or fail states) rather than colour alone.
How conformance is maintained. The practices under how we test apply to new pages and tools before release. Barriers reported through the feedback route are triaged by user impact, and the non-accessible content list above is updated when a limitation is confirmed or resolved.
Design and evaluation
How accessibility is supported
Review combines code-level practices, manual interaction checks, assistive-technology considerations, and automated testing. No single method can establish full WCAG conformance.
Zoom and reflow
Layouts are checked at narrow widths and increased zoom so content and controls remain readable without two-dimensional scrolling.
Semantics and assistive technology
Headings, landmarks, names, states, instructions, errors, and dynamic updates are reviewed with native semantics and screen-reader behavior in mind.
Automated checks
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.
Compatibility and technical basis
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
Report a barrier or request an alternative
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.
If you are not satisfied with the response, you can raise a complaint with the enforcement body or market surveillance authority responsible for accessibility in your country. For services used from the European Union, that is the authority designated under the European Accessibility Act in your member state.
Assessment and review record
- Last reviewed
- September 2, 2026
- Assessment type
- Internal review and development testing
- Compliance status
- Partially compliant with WCAG 2.2 AA
- Independent certification
- Not claimed
- Responsible operator
- Khushwant Parihar
This statement was prepared on July 13, 2026 and last reviewed on September 2, 2026. The September 2026 review added the compliance status in the prescribed wording, the list of non-accessible content, and the description of how the service meets the accessibility requirements, so that the statement satisfies the same checks the site's own accessibility statement checker applies. 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.