Legal and contact
Accessibility
How THREATBYTES™ approaches inclusive design, WCAG 2.2 AA, and reporting barriers on the research site.
THREATBYTES™ aims to make the public research website and platform usable by as many people as possible, including users who rely on assistive technologies. Accessibility is treated as a research-integrity and inclusion requirement, not an optional polish step.
We target conformance with the Web Content Accessibility Guidelines (WCAG) 2.2 at Level AA for public marketing pages, documentation, and core authenticated workflows. Full conformance across every experimental feature is a goal; known gaps are listed below.
Development practices include:
- Semantic HTML landmarks (header, main, nav, footer) and a skip link to main content. - Visible keyboard focus styles and logical tab order in the instrument UI theme. - Text alternatives for meaningful non-text content where implemented. - Colour contrast aligned with the Astryx / THREATBYTES design tokens; light and dark themes. - Responsive layout from 320px viewport width upward. - Form labels, error association, and aria attributes on primary navigation (including mega menus and search). - Reduced-motion support for homepage and research documentation animations where prefers-reduced-motion is set.
The site is designed for current versions of major browsers (Chrome, Firefox, Safari, Edge) on desktop and mobile. Some visualisations (for example Three.js hero and specimen experiences) may require WebGL; alternatives or static fallbacks are provided where feasible.
We are actively improving:
- Complex data visualisations and 3D views may not fully expose all state to screen readers; summaries are provided in parallel text where possible. - PDF or exported reports generated during research demos may not always meet PDF/UA without a dedicated export pass. - Third-party embedded content is limited; where added, we review accessibility impact.
If you encounter a barrier, please tell us via Contact so we can prioritise a fix.
We combine automated checks (linting, axe-style rules in CI where configured), manual keyboard testing, and periodic review of high-traffic templates (homepage, research documentation, database explorer, login). Formal third-party audits may be commissioned before production institutional launch.
If you need information in an alternative format (for example large print or structured plain text) or cannot access part of the site, contact us with the page URL and description of the issue. We will respond within a reasonable timeframe and track remediation.
If you are not satisfied with our response, you may contact the Equality Advisory and Support Service (EASS) or, for public-sector users, the relevant UK regulator once institutional hosting determines applicability.
Accessibility feedback: use the general contact route on the Contact page with the subject line "Accessibility".