CodBio Hub aims to make its public websites, documentation and interactive interfaces usable by people with different devices, input methods and accessibility needs.
Accessibility is treated as an ongoing design and development responsibility rather than a one-time feature.
This statement describes the accessibility and navigation practices used across CodBio Hub Home. Individual projects may provide additional accessibility information where their interfaces differ substantially.
1. Semantic page structure
Pages use semantic HTML structure where practical so browsers, assistive technologies and other software can better understand the organisation of the content.
This includes elements such as:
- headings in a meaningful hierarchy;
- navigation landmarks;
- main-content regions;
- lists and tables where structurally appropriate;
- buttons for actions;
- links for navigation;
- labelled form controls.
Visual appearance should not be the only way page structure is communicated.
2. Keyboard navigation
Interactive controls are intended to remain usable without requiring a mouse.
Keyboard users should be able to move through links, buttons, forms and other interactive components using standard browser controls such as the Tab key.
Custom interactions should preserve normal keyboard behaviour wherever practical rather than replacing established browser interaction patterns unnecessarily.
3. Focus visibility
Interactive elements provide visible focus states so keyboard users can identify which control is currently active.
Focus styling should remain distinguishable from ordinary hover states and should not rely solely on subtle colour changes.
Where scripted navigation moves attention to a specific document or interface section, focus is managed so that the destination can be identified without unnecessarily disrupting the user's position.
4. Skip navigation
Where provided, skip links allow keyboard and assistive-technology users to move past repeated interface elements and reach the primary page content more directly.
This is particularly useful on pages containing persistent headers, navigation menus or other repeated controls.
5. Responsive layout
CodBio Hub layouts are designed to adapt across desktop, tablet and mobile screen sizes.
Responsive behaviour aims to:
- avoid unnecessary horizontal scrolling;
- preserve readable text sizes;
- keep controls reachable;
- prevent important content from extending beyond the visible screen;
- reorganise multi-column layouts when space becomes limited.
Responsive design also supports users who enlarge browser content or work with narrow viewing areas.
6. Text and visual presentation
Readable contrast, spacing and typography are considered when designing public interfaces.
Content should remain understandable without relying entirely on colour, decorative graphics or animation.
Where icons or visual indicators carry meaning, accompanying text or accessible labelling should be used where appropriate.
7. Reduced motion
CodBio Hub respects the browser or operating-system prefers-reduced-motion setting where supported.
Users who request reduced motion should receive reduced or removed non-essential animation where practical.
Animations used for interface feedback should not be required in order to understand the underlying content or state.
8. Disclosure controls and expandable content
Expandable policy sections and similar interface components use native or accessibility-aware disclosure patterns.
Native HTML controls are preferred where they provide suitable behaviour because they include established keyboard and browser interaction semantics.
An expanded or collapsed state should remain understandable without relying only on animation.
9. Stable navigation and direct links
Policy documents and other structured content may use stable page hashes or identifiers.
These allow users to:
- link directly to a relevant section;
- return to a specific document;
- share a precise location;
- navigate without searching through the entire policy collection again.
Navigation to a direct link should preserve relevant page context where possible rather than unexpectedly resetting valid filters or user choices.
10. Search and filtering
Where policy or catalogue interfaces provide search and filters, these controls are intended to narrow content without changing the underlying meaning or availability of the documents.
Search results may visually highlight matching text to make the relevant part of a document easier to identify.
Filtering and pagination should remain consistent with the documents currently visible to the user.
11. Forms and feedback
Forms should provide labels, validation feedback and understandable error states.
Required information should not be communicated solely through colour.
Where a submitted value cannot be accepted, the interface should provide enough information for the user to understand what needs to be corrected.
12. Links and external destinations
Links should provide enough context for users to understand their purpose.
Where a link opens an external product, publication or third-party website, the destination may follow different accessibility practices from CodBio Hub.
CodBio Hub cannot control the accessibility of independently operated external websites.
13. Scientific and technical interfaces
Scientific software can contain complex tables, plots, workflow states and analytical controls.
Where possible, these interfaces should provide understandable labels, structured outputs and textual context rather than depending entirely on visual interpretation.
Some highly specialised scientific visualisations may present additional accessibility challenges. These should be improved progressively as the associated tools develop.
14. Assistive technologies and browser differences
Accessibility behaviour can vary between browsers, operating systems, assistive technologies and device configurations.
CodBio Hub therefore favours standard browser behaviour and semantic HTML where practical rather than relying unnecessarily on custom interaction models.
No single configuration is guaranteed to represent every user's experience.
15. Third-party components
Some CodBio Hub interfaces depend on external libraries, embedded services or third-party content.
Those components may have accessibility characteristics outside CodBio Hub's direct control.
Where a third-party component creates a significant barrier, alternative implementation approaches may be considered as the relevant project develops.
16. Current limitations
CodBio Hub is an actively developed ecosystem and accessibility may not yet be uniform across every project, historical page or experimental interface.
Some specialist research tools may require further refinement for:
- screen-reader interpretation;
- complex scientific visualisations;
- highly interactive analytical controls;
- very large tables or datasets;
- legacy project interfaces.
Known issues should be addressed progressively as interfaces are reviewed and updated.
17. Standards and approach
CodBio Hub accessibility work is informed by established web-accessibility practices, including the principles reflected in the Web Content Accessibility Guidelines (WCAG).
This statement does not represent a formal certification of conformance to a particular WCAG level unless such conformance is explicitly stated following appropriate assessment.
18. Accessibility feedback
Accessibility problems can be reported through the Contact page.
Where possible, include:
- the affected page;
- the control or content involved;
- what you were trying to do;
- the barrier encountered;
- the browser or device if relevant.
Do not include unnecessary sensitive personal or health information.
Accessibility feedback is useful for identifying barriers that may not appear during ordinary development and testing.
19. Ongoing improvement
Accessibility practices may be revised as CodBio Hub interfaces, technologies and projects develop.
The version and revision date shown with this policy indicate the current published statement.
20. Home 2.0 workspace interactions
The canonical Home 2.0 interface includes an application-like workspace shell while retaining ordinary web-navigation semantics.
Relevant accessibility behaviours include:
- the horizontal workspace tabs remain links and can be reached through normal keyboard navigation;
- scrollable tab and panel regions keep visible, themed scrollbars during interaction rather than hiding scrolling entirely;
- the mobile navigation drawer exposes the same canonical destinations without requiring hover;
- the desktop technical Context Inspector updates on both pointer hover and keyboard focus;
- an Inspector selection remains latched until another eligible item is selected, so a keyboard or pointer user can move into the Inspector and interact with its links or code controls;
- code examples use selectable text and labelled Copy controls;
- the command palette is an optional shortcut and does not replace the ordinary navigation routes.
Hover-only information should not be the sole route to essential content or navigation.
21. Conformance and legal scope
The Home interface is designed using WCAG-informed accessibility practices and is reviewed progressively as features change.
This policy does not claim formal WCAG certification or a particular conformance level without a dedicated assessment. Statutory accessibility obligations can also depend on the nature of a service, the applicable jurisdiction and any relevant exemptions or transition rules.
Where a specific legal accessibility requirement applies to a CodBio Hub service, that requirement should be assessed against the service actually being provided rather than inferred from this general statement.