Accessibility Statement

Last Updated: August 31, 2026

DCYFR Labs is committed to ensuring digital accessibility for all users, including those with disabilities. We target WCAG 2.1 Level AA across the estate, and we are working toward WCAG 2.2 Level AA and EN 301 549.

This statement describes what we have actually tested. Where a check has not been run, it is listed as a gap rather than left to inference.

How this statement was prepared

Method: self-assessment, carried out by DCYFR Labs
Basis: the automated checks listed under Testing and validation, plus a source review of the shared component library
Prepared by: DCYFR Labs. No third party has audited these sites
Date prepared: August 31, 2026
Review cadence: reviewed when the shared component library changes materially, and at least once a year

Scope and Conformance Status

This statement covers the DCYFR web estate: dcyfr.ai, dcyfr.io, dcyfr.app, dcyfr.bot, dcyfr.codes, dcyfr.tech, dcyfr.work and dcyfr.build.

All eight sites: partially conformant, WCAG 2.1 Level AA

Partial conformance means most of the standard is met and some parts are not yet verified. We describe every site this way, including dcyfr.ai, because no site in the estate has been through screen reader testing or a review by people who use assistive technology daily. Automated tooling catches a well-understood subset of WCAG failures. It does not establish conformance on its own, and we will not describe a site as fully conformant on the strength of it.

The seven sibling sites are built from the same component library as dcyfr.ai and inherit its keyboard, focus, contrast and semantic-structure behaviour. They carry less automated coverage than dcyfr.ai does.

Two surfaces carry more interaction than the rest and are our current priority for assessment:

The cost estimator on dcyfr.build, a multi-control form with live-updating results
The agent preview chat on dcyfr.bot, a streaming message log with a text input

If you hit a barrier on any of these, tell us and it goes to the front of the queue.

Known gaps

No screen reader testing has been performed on any site in the estate
No testing has been done with people who rely on assistive technology
No external accessibility audit has been commissioned
Automated route coverage on dcyfr.ai reaches five routes, so the rest of the site is unverified
The seven sibling sites have no automated accessibility coverage of their own
The two priority surfaces named above are untested
Third-party embedded content (video players, the giscus comment box) is outside our control and may not meet the same standard
WCAG 2.2 additions (focus appearance, dragging alternatives, target size) are not yet verified anywhere in the estate

Testing and Validation

What runs automatically

axe-core, through Playwright. Scoped to the wcag2a, wcag2aa, wcag21a and wcag21aa rule tags. It runs against /, /about, /blog, /contact and /projects on dcyfr.ai, on every pull request that touches the app and again nightly.
Lighthouse CI. Six routes on dcyfr.ai, with the accessibility category held at 85 or above. This is advisory and does not block a release.
A static contrast check. It reads the OKLCH design tokens out of the stylesheet and evaluates WCAG AA and AAA ratios in process. It checks token pairs; it does not open a page, so it says nothing about contrast against real composited backgrounds.

What we check by hand

Keyboard-only walkthroughs of new interactive components before they ship, covering tab order, focus visibility and escape behaviour
VoiceOver spot checks on macOS when a component’s semantics change

These are informal developer checks, not a structured assistive-technology review.

What we have not done

Listed under Known gaps above. The short version: no screen reader testing, no user testing, no external audit.

Accessibility Features

The following describe how the shared component library is built. They are design commitments backed by source review and the automated checks above, not claims of verified conformance on every page.

Keyboard Support: Navigate using Tab, Enter, Escape, and Arrow keys
Visible Focus Indicators: 2px outline on interactive elements
Logical Tab Order: Sequential navigation follows visual layout
Skip to Content Link: Bypass navigation and jump to main content
Command Palette: Quick access via Cmd/Ctrl+K keyboard shortcut

Semantic HTML: Proper heading hierarchy (h1 through h6)
ARIA Labels: Descriptive labels for interactive elements
Landmark Regions: Clear structure with header, nav, main, footer
Alternative Text: Meaningful images carry descriptive alt text
Descriptive Links: No “click here” or “read more” without context
Form Labels: Form inputs are labeled and associated

Visual Accessibility

Color Contrast: Minimum 4.5:1 for text, 3:1 for large text
Resizable Text: Zoom up to 200% without loss of content or functionality
No Color-Only Information: Information not conveyed by color alone
Dark Mode Support: System preference-based dark mode for reduced eye strain
Clear Typography: Readable fonts with adequate spacing and line height
Consistent Layout: Predictable navigation and structure throughout

Touch and Mobile Accessibility

Touch Targets: Minimum 44×44 CSS pixels for interactive elements
Responsive Design: Works on all screen sizes and orientations
No Hover-Only Content: Content is reachable via touch
Mobile Screen Readers: Built to standard semantics for VoiceOver and TalkBack, though neither has been tested on these sites

Content Accessibility

Plain Language: Clear, concise content without unnecessary jargon
Descriptive Headings: Clear section headings that describe content
Error Messages: Clear explanations with instructions to fix issues
Sufficient Time: Adequate time to read and interact with content
No Auto-Play: No automatically playing audio or video

Known Issues

Our open items are the gaps listed above, chiefly the absence of screen reader and assistive-technology testing across the estate. We are not aware of a specific unresolved barrier beyond those, which is not the same as there being none: the checks that would surface one have not all been run.

If you encounter a barrier, please tell us using the contact details below.

Feedback and Support

We welcome feedback on the accessibility of our sites. If you encounter an accessibility barrier:

Contact Methods

Contact Form: Submit feedback, subject “Accessibility Feedback”
GitHub Issues: Report accessibility issues

Response Time: We aim to respond within 5 working days.

What to Include

Description of the accessibility barrier
Page or feature affected
Assistive technology you’re using (if applicable)
Browser and operating system
Suggestions for improvement (if any)

Technical Specifications

Supported Browsers

Chrome (latest 2 versions)
Firefox (latest 2 versions)
Safari (latest 2 versions)
Edge (latest 2 versions)

Assistive Technology

These sites are built to the standard semantics that screen readers consume, so they are expected to work with NVDA, JAWS, VoiceOver and TalkBack. Only VoiceOver on macOS has been exercised, and only informally. Treat the rest as untested rather than supported.

Technologies Used

HTML5: Semantic markup for clear structure
CSS3: Responsive design with design tokens
TypeScript: Type-safe interactions
React 19: Accessible component library
Next.js 16: Server-side rendering for performance
ARIA 1.2: Accessible Rich Internet Applications

Standards and Guidelines

We work toward these accessibility standards:

WCAG 2.1 Level AA: Web Content Accessibility Guidelines (primary standard)
Section 508: U.S. federal accessibility standards
ARIA 1.2: Accessible Rich Internet Applications specification
EN 301 549: European accessibility standard

Continuous Improvement

Every pull request: axe-core and the static contrast check run against the app
Nightly: the full end-to-end suite, including the accessibility specs, runs again
At least annually: this statement is reviewed and re-dated

Closing the gaps listed above, starting with screen reader coverage of the two priority surfaces, is the current plan of record.

Privacy Policy - How we protect your data
Terms of Service - Legal agreements
Security Policy - Our security measures
Contact Us - Get in touch

DCYFR Labs Accessibility Statement We target WCAG 2.1 AA and say plainly where we have not yet verified it. Questions or accessibility concerns? Contact us.