Accessibility Statement

Standards & practices

The site is built on a foundation of standards-based, semantic web practices. We align our work with the Web Content Accessibility Guidelines (WCAG) 2.1 and 2.2, Level AA, and apply these practices across every page:

• Semantic HTML landmarks (header, nav, main, footer) structure every page so assistive technology can navigate content reliably.
• Proper heading hierarchy - a single h1 per page, followed by logically nested h2/h3 sections.
• ARIA roles and attributes are applied only where native semantics fall short (e.g. mobile menu toggle, copy buttons, live response regions).
• Full keyboard navigability - every interactive element is reachable and operable without a pointing device, and a skip-to-content link is provided on every page.

Visual accessibility

• Color contrast ratios meet or exceed WCAG AA in both light and dark themes; text never relies on color alone to communicate meaning.
• Light and dark themes are fully supported, with the user's preference remembered and a manual toggle available in the navigation bar.
• Focus indicators are clearly visible on all focusable elements, including links, buttons, form fields, and custom interactive controls.
• Responsive design reflows comfortably from small mobile viewports up to large desktop screens, and remains readable at browser zoom levels up to 200%.

Motion & interaction

• Animations across the site are intentionally subtle - used to guide attention and provide feedback, never to distract or disorient.
• The user's prefers-reduced-motion system setting is respected: decorative transitions, ambient motion, and reveal animations are automatically suppressed when this preference is enabled.
• No auto-playing, flashing, or rapidly-scaling effects are used anywhere on the site.

Multi-language & internationalization

The Bible API serves content across many writing systems. We take deliberate steps to keep this content accessible regardless of language:

• All responses are served as valid UTF-8, so non-Latin scripts (e.g. Chinese 聖經, Hebrew תורה, Cherokee ᎠᏂᎩᏓᏗ) render correctly in browsers, screen readers, and terminal tooling.
• Typography fallbacks cover broad Unicode ranges, so scripts without a dedicated web font still render legibly.
• The response schema is consistent across every translation - the same keys (book, chapter, verse, text, translation) are returned in every language, which benefits screen readers, automated tooling, and downstream accessibility pipelines.
• Where a translation has partial coverage, missing books are clearly marked in the documentation so users of assistive tools are not surprised by empty or unavailable content.

Forms & input accessibility

• Every form input is paired with an explicit <label> association, so screen readers always announce the purpose of a field.
• Error and status messages are communicated in plain language and, where appropriate, exposed via aria-live regions so updates are announced without requiring focus changes.
• Interactive controls - including the Playground, Snippets previews, and search inputs - are fully operable by keyboard and provide visible focus states at every step.

Continuous improvement

Accessibility is an ongoing commitment, not a finished checklist. We continue to audit the site as new pages and features are added, and we welcome feedback from the people who use it.

If you encounter an accessibility barrier - or have a suggestion for how we can do better - please reach out through the contact page with the subject "Accessibility". Reports are treated with the same priority as any other defect.