Inclusive access to Britixo information

Accessibility statement

Britixo designs digital experiences to be understandable, keyboard operable, responsive and compatible with common assistive technologies.

Original Britixo illustration for Accessibility statement

Report a barrier: Email hello@britixo.com with the page, task, device or assistive technology and what prevented completion. Do not include unnecessary sensitive information.

1. Our approach

Accessibility is treated as a quality requirement for the complete user journey, not as an overlay added after design. The website uses semantic HTML, visible focus states, labelled controls, responsive layouts, plain-language navigation and progressive enhancement so core information remains available when optional scripts do not run.

The design aims to support visitors who navigate by keyboard, use screen readers, magnify content, prefer reduced motion, use touch or voice input, or read on a small screen and slower connection. Different people combine these needs, so no single automated score can prove that a page is accessible.

2. Navigation and structure

A skip link allows keyboard users to move directly to the main content. The header uses nested menus with buttons that expose their expanded state. On smaller screens the same hierarchy becomes an accordion-style menu rather than relying on hover. Escape closes open navigation and focus remains visible.

Pages use one main heading followed by descriptive sections. Section headings can be linked directly, and cards use meaningful destination text instead of repeated “click here” labels. Breadcrumbs provide context on deeper service, insight, sector and location routes.

3. Keyboard and focus

Links, buttons, form controls, disclosure panels and menu toggles can be reached using the keyboard. Focus indicators are designed to remain visible against the surrounding surface. Interactive cards contain real links or native disclosure controls rather than relying on a mouse-only script.

Keyboard order follows document order. The website avoids trapping focus inside custom components. If a future modal, chat tool or embedded service is introduced, it should be checked for focus management, labelling and a reliable route to close it.

4. Responsive layout and zoom

Content reflows from desktop columns into single-column mobile layouts. Fixed-width text blocks are avoided, controls remain large enough to operate and horizontal scrolling should not be required for normal page content at supported widths. Browser zoom and text resizing should preserve reading order and access to navigation.

Long city directories include a text search that filters existing links without removing access to the underlying page structure. The result message is announced through visible content rather than colour alone.

5. Colour, motion and images

Text and important controls use contrasting foregrounds, borders and focus states. Meaning is not communicated only by colour. Abstract SVG artwork has an accessible label and does not contain information required to understand the page.

Animations are limited to opacity and transform-based movement. A reduced-motion preference disables reveal and decorative transitions. The core content is visible without animation, and interaction does not depend on movement completing.

6. Forms and feedback

The contact form uses explicit labels, required-field indicators, native browser validation and a status region. Instructions explain that the form prepares an email locally and that sensitive material should not be placed in an initial message. The privacy notice is linked before submission.

A production server-side form, spam control or third-party booking tool would need a new accessibility review. Error messages should identify the field and correction in text, preserve entered information and move focus predictably where an error summary is used.

7. Language and readability

The document language is declared as British English. Pages aim to explain technical terms in context, keep paragraphs manageable and connect recommendations to business outcomes. Detailed content is divided with headings, lists, cards and disclosure panels so visitors can scan before reading in depth.

Minimum word counts are not used as an excuse to repeat keywords or hide text. Each page should answer the question implied by its route and provide a clear next step.

8. Known limits

The website has not been tested with every browser, device, screen reader, speech-input product or personal configuration. Generated abstract artwork uses concise labels rather than long descriptions because it is thematic and does not carry decision-critical meaning. Legal entity details and final production form handling still require confirmation before launch.

Third-party documents or services introduced later may have their own limitations. Britixo should avoid adding an external component until its keyboard, labelling, reflow, privacy and performance have been reviewed.

9. Testing and maintenance

Representative pages should be checked with keyboard-only navigation, browser zoom, reduced motion, mobile reflow and common screen-reader combinations. Automated tools can help identify missing names, invalid structure and some contrast issues, but human task testing remains necessary.

Accessibility can regress when templates, content, forms or navigation change. Shared components should be regression-tested, and editorial review should cover heading order, link purpose, alternative text, tables, captions and plain language.

10. Feedback and alternative access

If a barrier prevents access to information or a task, email hello@britixo.com. Include the page address and what you were trying to do. Britixo should investigate, correct the shared component where possible and provide the information in a reasonable alternative format.

Urgent technology or security enquiries should identify the business impact in the subject, but accessibility feedback should not contain passwords, confidential records or detailed vulnerabilities.

A useful first conversation

Found an accessibility barrier?

Tell Britixo which page and task were affected so the issue can be investigated and the information provided another way where possible.

Decision checklist

Questions worth answering before you invest

A small number of clear decisions usually creates more progress than a long list of technology activity.

Inclusive and maintainable web access becomes useful when the organisation can connect it to a service, an owner and a measurable result. Britixo uses the questions below to expose assumptions early and shape a proportionate first step.

  • Which business service or user outcome should improve through inclusive and maintainable web access?
  • Who owns the decision, the live service and the remaining risk?
  • Which dependencies, suppliers and information need to be understood before change?
  • What evidence will show that the work has improved reliability, experience, security or cost?
  • How will the organisation support, recover and continue improving the result after launch?

The answers do not need to be complete before the first conversation. Their purpose is to identify the evidence, people and decisions that should form the initial scope.