Our commitment

The Living Chronicle is a small publisher run by Aegis Brightsmark Capital MB. We are committed to making thelivingchronicle.com and the The Living Chronicle apps on iOS and Android as accessible as we reasonably can, to the WCAG 2.2 Level AA standard published by the W3C Web Accessibility Initiative.

Accessibility is not a task we finish and move on from. It is a running commitment — we review the site against WCAG at every launch-readiness cycle, fix what we find, and document the known gaps so you know what to expect.

Current compliance

As of the date at the top of this page, we believe the public web surface — marketing, funnel, lore wiki, blog, help center, podcast, developer portal, legal pages — conforms to WCAG 2.2 AA with the exceptions listed under "Known limitations" below.

Specifically, we have verified the following primitives:

Keyboard navigation. Every interactive element is reachable via Tab / Shift+Tab, and a "Skip to main content" link at the top of every page lets keyboard users bypass the navigation on each visit.
Focus visibility. A 2-pixel high-contrast outline is visible on every focused element, meeting the WCAG 2.2 SC 2.4.13 Focus Appearance (Level AAA) guidance.
Reduced motion. Every animation, transition, and auto-playing effect is collapsed when your operating system has "Reduce motion" enabled.
Text contrast. Primary body text on the site's dark background measures 17.4:1 contrast — more than double the AAA requirement of 7:1. Secondary text, accents, and error states are all above the AA threshold of 4.5:1.
Form labels. Every input on the waitlist, support ticket, email preferences, login, and admin forms is explicitly labeled and announces success and error viarole="status", aria-live="polite", and role="alert".
Landmarks. Every page uses semantic <nav>, <main>, <footer>, and heading structure (single H1, no skipped levels). Breadcrumb trails on content-heavy pages carry aria-current="page" on the current location.
Screen reader language. The <html lang> attribute is set to the active locale (English by default, or Spanish, French, German, Portuguese, Japanese if the visitor picks one).

Known limitations

These are gaps we are aware of and working on:

Image alt text. The site currently ships no photographic screenshots — every visual is CSS or decorative SVG. When real screenshots and character art land later, we will wire them through next/image with descriptive alt attributes. Target: with the visual identity drop.
Landing page animation weight. The hero and below-the-fold marketing sections use Framer Motion, which the reduced-motion rule silences but which still adds JS to the initial bundle. We plan to swap them for CSS keyframes in the bundle-size audit task. Target: before production launch.
Non-English statement. This statement is currently English-only. We will translate it alongside the broader i18n pass on legal and help content. Target: Q2 2026.
Screen-reader QA. We have done static structural checks but have not yet tested every page with NVDA on Windows and VoiceOver on macOS / iOS. Manual screen-reader review is part of the pre-launch quality gates. Target: pre-launch sweep.
Dev portal playground. /developers/playground contains a rich interactive API explorer that has not yet been fully audited for keyboard access to every endpoint parameter. We do not yet claim AA conformance for the playground specifically.

Third-party content

Some elements on the site are outside our direct control:

Store buttons. The Apple App Store and Google Play download buttons link out to third-party destinations whose accessibility is managed by Apple and Google respectively.
Podcast subscribe links. Links on the podcast page hand off to Apple Podcasts, Spotify, Google Podcasts, and RSS readers — each with their own accessibility profile.
Social embeds. Where we link to Discord or X, the linked destination is governed by the platform's own accessibility practices.
Analytics and consent. Vercel Analytics loads only after you opt in to analytics cookies; the opt-in banner itself meets WCAG AA.

Assistive technologies we test against

Our target set for AA conformance is:

NVDA (latest) on Windows 11 with Chrome and Firefox
VoiceOver on macOS (latest Safari) and iOS (latest Safari)
TalkBack on Android with Chrome
Keyboard-only navigation on all major desktop browsers
Browser zoom up to 400%

How to report an accessibility issue

If you find a page, flow, or feature that gets in your way, please tell us — this is how we find most of the gaps that static auditing misses. You can contact us in several ways:

Email: accessibility@aegisbrightsmark.com — monitored by the engineering team. We respond within 5 business days.
Support ticket: Open a ticket at /help/contact and pick the "Technical issue" or "Other" category. Accessibility reports are escalated internally on the same SLA as safety issues — first response within 4 hours.
Postal: Aegis Brightsmark Capital MB, Sembu 6, Buivydiskes, LT-14166, Vilniaus raj., Lithuania.

When you report an issue, if you can include the URL, your browser and operating system, the assistive technology you are using (if any), and a short description of what happened and what you expected, it helps us reproduce the problem faster.

Formal complaints

If you have contacted us and are not satisfied with our response, you can file a complaint with the Lithuanian State Data Protection Inspectorate (for data-related accessibility issues) or with your local equalities body. The Chronicle is published from Lithuania, but we take reports from anywhere in the world.

Enforcement

This statement is issued in good faith. We do not claim perfect compliance — accessibility is a moving target and we may have missed something. If you find something we missed, please let us know before you publish a formal complaint so we have a chance to fix it quickly.

For general inquiries unrelated to accessibility, please use info@aegisbrightsmark.com.