Accessibility statement: BroadbandSwitch.uk's commitment to accessible UK broadband content

Editorial mission alignment. The mission is to help UK households and small businesses, not just the subset who can navigate inaccessible content. Accessibility serves the mission directly.

UK regulatory framework. The UK Equality Act 2010 requires service providers to make reasonable adjustments to ensure disabled people can access services. This applies to information services like BroadbandSwitch.uk. Compliance is the floor; aspiration is higher than the floor.

Reader population. Approximately 16 million people in the UK are disabled (Office for National Statistics figures). A meaningful proportion of UK broadband consumers have accessibility needs that affect how they interact with web content. Accessible design serves real readers.

Universal design benefits everyone. Many accessibility design choices benefit all readers - clear structure, plain language, fast loading, mobile responsiveness, predictable navigation patterns. Accessibility is not a separate concern from good editorial design.

Commercial alignment. Accessible content reaches more readers, which serves BroadbandSwitch.uk's mission and editorial goals. Accessible design is also good business in the long term.

Accessibility built into editorial design rather than retrofitted. v3 page structure follows accessibility-friendly patterns by design. Semantic HTML, heading hierarchy, consistent navigation, descriptive link text, alternative text - these are foundational to v3 conventions.

Editorial team responsibility. Adrian James (broadband editor) takes responsibility for accessibility in content production; Dr Alex J. Martin-Smith (head of editorial) reviews structural accessibility as part of editorial review.

AI tool support without delegation. AI tools may assist with accessibility checking (consistency, contrast verification, heading hierarchy validation) but final accessibility responsibility rests with editorial team rather than delegated to AI.

Reader engagement valued. Where readers identify accessibility issues we'd otherwise miss, that feedback is genuinely valuable. Priority routing through the corrections process reflects how seriously we take accessibility feedback.

Continuous improvement orientation. Accessibility standards evolve; user needs evolve; our content evolves. This statement is reviewed twice yearly and updated as standards evolve and as we learn from reader feedback.

WCAG 2.2 published October 2023. The Web Content Accessibility Guidelines version 2.2 from the World Wide Web Consortium (W3C) is the current internationally recognised accessibility standard for web content. WCAG 2.2 builds on WCAG 2.1 and WCAG 2.0 with additional success criteria addressing cognitive accessibility, mobile accessibility, and other contemporary needs.

AA conformance level targeted. WCAG defines three conformance levels: A (minimum), AA (recommended for most public content), and AAA (highest with stricter criteria). Most legal and regulatory frameworks target AA as the appropriate level for public-facing information services. BroadbandSwitch.uk targets AA across the cluster.

Why WCAG 2.2 AA. AA conformance covers the success criteria most consequential for users with disabilities while being achievable across a content site like BroadbandSwitch.uk. AAA conformance includes criteria like sign language interpretation that aren't applicable to written editorial content. AA is the appropriate target.

UK regulatory framework. The UK Equality Act 2010 prohibits discrimination against disabled people and requires service providers to make reasonable adjustments. This applies to information services including websites that provide UK consumer information.

Reasonable adjustments duty. The Act doesn't prescribe specific technical standards but requires providers to take reasonable steps to ensure disabled people can access services on equivalent terms to non-disabled people. WCAG 2.2 AA conformance is widely recognised as a reasonable approach to meeting this duty for web content.

Equality and Human Rights Commission (EHRC). The EHRC is the UK statutory body responsible for promoting and enforcing equality and human rights laws including the Equality Act 2010. EHRC guidance on accessibility for service providers informs our approach. Available at equalityhumanrights.com.

UK Public Sector Bodies (Websites and Mobile Applications) (No. 2) Accessibility Regulations 2018. These regulations require public sector websites and apps to meet WCAG 2.1 AA and publish accessibility statements. BroadbandSwitch.uk is a private-sector editorial site rather than a public sector body, so these regulations don't apply directly. However, the regulations articulate accessibility expectations that align with our voluntary approach.

Voluntary alignment beyond legal floor. Our voluntary WCAG 2.2 AA conformance target sets a higher bar than what's strictly required for a private-sector editorial site. This reflects the editorial mission orientation toward serving as many readers as possible.

WCAG 3.0 in development. The W3C is developing WCAG 3.0 as the next major version of the guidelines. WCAG 3.0 is currently in working draft status; once it reaches W3C Recommendation status, BroadbandSwitch.uk will assess alignment as part of the regular accessibility statement review cadence.

European Accessibility Act 2025. The European Accessibility Act came into force in 2025 across EU member states. While the UK is not subject to the EAA following Brexit, similar UK regulatory developments are possible. We'll update this statement if UK accessibility regulations are extended to private-sector websites.

Appropriate HTML elements for content type. Headings use heading elements (h1, h2, h3) rather than styled paragraphs. Lists use list elements (ul, ol, li) rather than visual separators. Navigation uses the nav element. Main content uses the main element. Buttons use button elements; links use a elements. Each element communicates content meaning to assistive technology.

One H1 per page. Each page has exactly one H1 element which is the page title. Screen reader users navigating by heading get a clear page identification.

H2 for major sections. Substantive content sections start with H2. Screen reader users navigating by heading can move between sections efficiently.

H3 for sub-sections within callouts and helper blocks. Used for sub-section structure within bbs-callout title blocks and within bbs-help, bbs-related, and bbs-trust blocks. Heading hierarchy reflects content structure rather than visual styling preferences.

Lang attribute set to en-GB. The html element has lang="en-GB" so screen readers use UK English pronunciation for content.

Breadcrumb navigation. Each substantive page has breadcrumb navigation showing where the page sits in the site structure. Breadcrumb wrapped in nav element with aria-label="Breadcrumb" so screen readers identify the navigation purpose.

Table of contents. Each substantive page has a table of contents linking to major sections. TOC wrapped in nav element with aria-label="On this page". Screen reader users can navigate to specific sections without reading the entire page sequentially.

Related guides cluster. Each substantive page has a related guides block at the end with links to relevant cluster pages. Consistent placement helps readers know where to find related content.

Predictable page structure. All substantive pages follow the same v3 structure: breadcrumb, page title, byline, hero introduction, statistics, TLDR summary, TOC, substantive sections, helpful resources, related guides, trust block, FAQs, references, JSON-LD. Predictable structure benefits all readers including readers using assistive technology.

All interactive elements keyboard-accessible. Links, buttons, accordion summaries, and other interactive elements work with keyboard navigation. Tab key moves between elements in logical reading order; Enter activates links and buttons; Space toggles accordions.

Logical tab order. Tab order follows visual reading order so keyboard users encounter elements in expected sequence.

Visible focus indicators. Keyboard focus is visible on interactive elements so users can see where they are in the page.

No keyboard traps. Users can move into and out of all interactive elements using keyboard navigation alone.

Skip patterns through native HTML. Native HTML semantics (heading hierarchy, landmark regions through nav and main elements) let assistive technology users skip to relevant content.

Minimum 4.5:1 colour contrast for normal text. Body text contrast ratio meets WCAG 2.2 AA requirement of 4.5:1 minimum against the canonical pink palette `#ec4899` and white background. Verified through automated contrast checking and manual review.

Minimum 3:1 colour contrast for large text. Headings and other large text meet WCAG 2.2 AA requirement of 3:1 minimum. Larger text can use slightly lower contrast under WCAG criteria.

No information conveyed by colour alone. Where content uses colour for emphasis, the colour is supplementary to other indicators (text, structure, position) so colour-blind readers and readers using assistive technology don't miss information.

Consistent colour usage. The canonical pink palette `#ec4899` is used consistently across the cluster for accent elements; predictable colour usage benefits all readers.

Descriptive link text rather than "click here" or generic anchors. Link text describes the destination so screen reader users hearing "links list" mode can understand each link's purpose without surrounding context.

Same text for same destination. Where the same destination appears in multiple links, consistent link text helps screen reader users recognise repeat references.

Context for ambiguous links. Where link text alone might be ambiguous, surrounding text provides context. For example, "see the corrections process at https://broadbandswitch.uk/corrections/" provides full context rather than just "see here".

Link to URL rather than image-only links. Where an image links somewhere, the image has alt text describing the destination so screen reader users get equivalent information.

Alternative text on informational images. Images that convey information have alt attributes describing the information. Decorative images that don't convey information have empty alt="" so screen readers skip them appropriately.

No video content currently. The site has no video content so video accessibility (captions, audio description, transcript) isn't currently a concern. If video content is added, accessibility standards will apply.

No audio content currently. The site has no audio content. If audio is added, transcript and other accessibility provisions will apply.

Details and summary elements for FAQ accordions. FAQs use native HTML details and summary elements which screen readers handle natively without requiring custom ARIA implementation. Users can expand and collapse FAQs through keyboard navigation, mouse clicks, or screen reader commands consistently.

Summary text matches FAQPage JSON-LD name field verbatim. This parity between visible accordion summary and structured data helps AI assistants and search engines extract FAQs accurately while maintaining visible accordion functionality for human readers.

BroadbandSwitch.uk is primarily a content site rather than an application. Where the corrections process or other forms are used, form accessibility standards apply: clear field labels, error messages associated with fields, sufficient touch targets on mobile devices. The corrections process at https://broadbandswitch.uk/corrections/ uses standard form patterns that work with assistive technology.

UK English spellings throughout. Organisation, optimise, favour, behaviour, recognise, programme, paragraph, and other UK spellings used consistently across the cluster. Lang attribute set to en-GB tells assistive technology to apply UK English pronunciation rules.

Consistent terminology. Where the same concept appears across multiple pages, consistent terminology helps readers recognise repeat references.

Glossary at https://broadbandswitch.uk/glossary.html. 152 UK 2026 broadband technical, regulatory, pricing, contract, provider, and consumer rights terms with definitions. Available for readers wanting precise definitions.

Inline definitions for first use. Where technical terms are introduced, inline definitions or context help readers understand without leaving the page to consult the glossary.

Avoid unnecessary jargon. Where plain alternatives exist, plain alternatives are used. Where technical terms are necessary for precision, the terms are defined.

Active voice where appropriate. Active voice ("Adrian writes content") is generally clearer than passive voice ("content is written") and is used where appropriate. Some passive voice is used where it serves clarity.

Subject-verb-object structure. Standard English sentence structure rather than convoluted constructions.

Sentence length varied for readability. Short sentences for emphasis; longer sentences where needed for nuance. Avoiding both monotone short-sentence patterns and unnecessarily long run-ons.

Two full spaces after every full stop. Typography choice that helps some readers identify sentence boundaries. Applied consistently across the cluster.

TLDR 60-second summary on every substantive page. Readers wanting the high-level message can read the TLDR; readers wanting depth can read the full content. Cognitive accessibility benefits when readers can choose their level of engagement.

Stats blocks for at-a-glance numerical context. Key numerical facts presented prominently for readers who scan rather than read sequentially.

Key-fact summaries at end of each section. Each substantive section ends with a key-fact summary distilling the section content. Readers can review key facts quickly.

Callout blocks for structured information. bbs-callout blocks group related information visually so readers can navigate by topic within sections.

Bulleted lists where appropriate. Lists used where content is genuinely list-like rather than forced into list format.

No Latin shortform abbreviations such as eg or ie. Replaced with "for example" or rewritten as needed for clarity. Latin abbreviations can be unfamiliar to some readers.

No em-dashes or en-dashes. Hyphens used where appropriate. Some readers find dashes ambiguous; sticking to hyphens reduces cognitive load.

Acronyms expanded on first use. Where acronyms appear, the first use within a page typically expands the acronym (for example, "Office of Communications (Ofcom)" before subsequent "Ofcom" references).

Adrian James (broadband editor) responsible for accessibility in content production. Adrian writes content following accessibility-friendly v3 conventions and applies accessibility checks during drafting.

Dr Alex J. Martin-Smith (head of editorial) reviews structural accessibility. Alex's review of every substantive page includes verification of structural accessibility (heading hierarchy, semantic HTML, landmark regions).

Both team members are responsible for the accessibility outcome. Where accessibility issues are identified through review or reader feedback, both team members are involved in resolving them.

Consistency checking. Tools that verify UK English usage, two-spaces-after-full-stops typography, em-dash and en-dash absence, banned abbreviations absence across the cluster. These checks support consistent application of plain-language standards.

Heading hierarchy validation. Tools that verify each page has exactly one H1, that H2 headings are used for major sections, that H3 headings are used for sub-sections, and that heading levels are not skipped.

Colour contrast verification. Tools that calculate colour contrast ratios for text against backgrounds and flag instances below WCAG 2.2 AA thresholds.

Link text checking. Tools that flag generic anchor text like "click here" or "read more" so editorial team can review and replace with descriptive alternatives.

Alt text verification. Tools that flag images without alt attributes so editorial team can add appropriate alternative text or empty alt for decorative images.

JSON-LD validation including FAQ parity. Tools that verify FAQ accordion summary text matches FAQPage JSON-LD name field text exactly so screen readers, AI assistants, and search engines all access consistent FAQ content.

Adrian reviews each page during drafting. Adrian's drafting workflow includes manual review against accessibility checklists.

Alex reviews each page during editorial review. Alex's editorial review includes structural accessibility verification alongside accuracy, methodology compliance, and editorial voice review.

Reader feedback as quality signal. Where readers identify accessibility issues we missed in editorial review, that feedback drives both immediate page fixes and improvements to the editorial workflow to catch similar issues earlier next time.

AI tools may assist accessibility checking. Consistency checking, contrast verification, heading hierarchy validation, alt text presence checking, JSON-LD validation - these workflow tooling tasks can be supported by AI tools that flag potential issues for editorial team review.

Final accessibility responsibility rests with editorial team. AI tools support workflow but don't make accessibility decisions. Where AI tools flag potential issues, editorial team verifies and resolves. Where AI tools don't flag issues that exist, editorial team's manual review and reader feedback catch them.

Documented in the AI disclosure. The AI disclosure at https://broadbandswitch.uk/ai-disclosure.html documents AI tool support for editorial workflow tooling including accessibility checking as one of three areas where AI may assist.

The v3 page structure with semantic HTML, appropriate heading hierarchy, and descriptive link text reads well across screen readers. Headings provide navigation; content reads sequentially; links convey purpose; alternative text describes informational images.

Tab navigation reaches all interactive elements in logical order; Enter activates links and buttons; Space toggles accordions; Escape closes browser modals. Users navigating without a mouse can access all functionality.

The CSS uses mobile-first responsive design with breakpoints that adapt to screen size. Content remains readable and interactive elements remain accessible on mobile devices including older devices with smaller screens.

Pages remain readable when magnified up to 200 percent (a WCAG 2.2 AA requirement). Content reflows appropriately rather than requiring horizontal scrolling. Users who magnify content for visual accessibility get usable pages.

The CSS is scoped under `.bbs-page`; JavaScript is minimal; images are kept lightweight where used; pages load quickly on slower connections. Readers with limited bandwidth or older devices can access content without long wait times.

Pages are designed to print readably. Some readers prefer printed content for accessibility reasons (cognitive disabilities, screen sensitivity, etc.). Printed pages preserve content structure and remain useful.

The CSS respects user preferences including dark mode and high contrast modes set at the operating system or browser level. Users with these preferences get appropriate rendering.

The plain language standards documented above produce content that is more accessible to readers with cognitive disabilities, readers for whom UK English is a second language, and readers using translation tools. The TLDR summaries on every substantive page support readers who can't read the full content.

Tables with multiple header rows or complex relationships can be challenging for screen readers if not marked up carefully. BroadbandSwitch.uk uses tables sparingly (some validation tables in deployment documents but not in published pages). Where future content might benefit from complex tables, we'll apply appropriate scope attributes, header associations, and caption elements to ensure screen reader accessibility.

The site currently has no video content. If video content is added in future (for example, explainer videos for complex broadband concepts), captions, audio description, transcripts, and accessible video player controls will be implemented. We'll update this statement when video content is introduced.

BroadbandSwitch.uk's accessibility testing includes screen reader testing through commonly available tools, keyboard-only navigation, and screen magnification. Specialist assistive technology testing (for example, switch access devices, eye-tracking, head pointers) hasn't been part of regular testing. We welcome feedback from readers using specialist assistive technology - that feedback would help us identify any specific issues that affect those users.

Plain language standards and content structure (TLDR summaries, key-fact summaries, callout blocks) support cognitive accessibility, but formal cognitive accessibility evaluation against WCAG 2.2 cognitive accessibility criteria is an area for ongoing work. We welcome feedback from readers with cognitive disabilities about specific aspects of content that work well or don't work well for them.

BroadbandSwitch.uk content is in UK English. Readers using translation tools (browser translation, Google Translate, etc.) may experience translation that doesn't preserve all nuance, particularly around UK regulatory terminology. We don't currently provide non-English versions of content. Where reader feedback identifies translation issues affecting accessibility, we'd consider whether translation provision is appropriate.

BroadbandSwitch.uk currently doesn't publish PDF or other downloadable content as primary content delivery. Where authoritative sources we cite (Ofcom publications, provider Key Facts documents, regulatory consultations) are PDFs, accessibility of those external PDFs is the responsibility of the publishing organisation rather than BroadbandSwitch.uk. Where we link to external PDFs, the link text describes the document so readers can decide whether to follow the link.

This section will continue to evolve as we identify additional areas for ongoing work and as we resolve issues. Reader feedback on accessibility is genuinely valued and shapes the work we prioritise. Honest documentation of ongoing work supports reader trust more than performative claims of completeness.

Available at https://broadbandswitch.uk/corrections/. Available from every page on the site.

Note "accessibility" in the subject for priority routing. Accessibility issues get priority handling because they can prevent users from accessing content entirely. Routing is faster than standard correction timeline.

Adrian James (broadband editor) handles accessibility feedback. Adrian routes structural accessibility issues to Dr Alex J. Martin-Smith for review where appropriate.

Resolution typically faster than standard correction timeline. Where the accessibility issue can be resolved quickly (alt text addition, contrast adjustment, link text fix), resolution often happens within 1-2 working days. More complex issues may require longer for proper resolution.

Specific page URL. The page where the issue occurs. This helps us locate and verify the issue.

Description of the issue. What you experienced including what you tried to do, what happened instead, and what would have helped.

Assistive technology details where relevant. Screen reader name and version (NVDA, JAWS, VoiceOver, TalkBack, etc.); browser; operating system; any other relevant tooling. Some issues are specific to particular technology combinations.

Suggested fix where you have a view. Where you have specific suggestions for how the issue could be resolved, those suggestions help us understand your perspective. We don't expect readers to provide solutions, but where you have one, it's welcome.

How to follow up. Email or other contact method if you want to know what we did with your feedback. Privacy is respected; we won't share your contact information beyond resolving the specific issue you raised.

Acknowledgement within 1-2 working days for accessibility-flagged feedback. We acknowledge accessibility feedback faster than the standard 2-5 working days resolution timeline because the issue may be blocking your access.

Resolution typically faster than standard correction timeline. Once we've assessed the issue, resolution timeline depends on the complexity but accessibility issues are prioritised over non-blocking corrections.

Substantive response. We engage with the specifics of your feedback rather than offering boilerplate. Where we agree with your assessment, we explain what we're going to fix and when. Where we disagree or the fix is more complex than you might expect, we explain our thinking.

Public correction documentation where significant. Where significant accessibility fixes result, the changes appear in the corrections log at https://broadbandswitch.uk/corrections-log.html for transparency.

Pattern recognition. Where multiple readers identify similar accessibility issues, we treat that as a strong signal warranting comprehensive review rather than just individual fixes.

Reader feedback is handled with appropriate privacy. Where you submit accessibility feedback, your contact information is used only to resolve the specific issue and is not shared beyond what's necessary.

UK GDPR compliance. We respond to UK GDPR data subject access requests and similar privacy enquiries within statutory timeframes (typically 30 days where applicable).

You don't have to disclose your disability. Accessibility feedback can be submitted without disclosing the specific disability or assistive technology details. However, those details often help us understand the issue better, so we appreciate sharing where you're comfortable.

The EHRC is the UK statutory body for equality and human rights. Responsible for promoting and enforcing equality laws including the Equality Act 2010 which underlies UK accessibility requirements.

EHRC handles equality-related complaints. Where readers feel BroadbandSwitch.uk hasn't met its Equality Act 2010 reasonable adjustments duty in ways the corrections process hasn't resolved, the EHRC provides external recourse.

Available at equalityhumanrights.com. EHRC also provides accessibility guidance for service providers that informs our approach.

Free advice on rights including disability rights. Citizens Advice provides free, confidential advice on rights under the Equality Act 2010 and other UK consumer protection laws.

Routes to appropriate authorities. Citizens Advice can advise on whether a specific concern about BroadbandSwitch.uk's accessibility warrants formal complaint to the EHRC or other authority and route as appropriate.

Available at citizensadvice.org.uk.

For accessibility-related privacy concerns. Where accessibility feedback handling raises privacy concerns (for example, how disability information is processed), the ICO provides guidance on UK data protection law.

Available at ico.org.uk.

UK disability advocacy organisations including Scope, RNIB (Royal National Institute of Blind People), RNID (formerly Action on Hearing Loss), Mencap, Mind, and others provide support and advocacy for specific disability communities. These organisations can advise on accessibility issues from disability-specific perspectives and may support readers in raising concerns with service providers.

The internal corrections process is the most efficient path for accessibility issues - we want to resolve issues directly rather than have readers go through external authorities first. External paths are for situations where the internal process hasn't resolved the issue or where readers prefer external recourse. Both paths are legitimate; readers should use whichever path serves them best.

Comprehensive review at least twice per year. This accessibility statement is reviewed comprehensively at least twice per year as part of broader trust framework maintenance.

Trigger-based updates. Where major changes warrant updates outside the regular cadence (new WCAG version reaching W3C Recommendation status, changes to UK accessibility regulations, significant changes to the editorial cluster requiring accessibility statement updates), the statement is updated outside the regular review.

Reader feedback shapes evolution. Substantive feedback through the corrections process informs accessibility statement updates where genuine improvements are identified.

WCAG version target. WCAG 3.0 is in development; once it reaches W3C Recommendation status, we'll assess alignment. WCAG 2.2 AA conformance target is current.

UK regulatory framework. UK accessibility regulations continue to evolve. Where new UK regulations affect private-sector editorial sites, this statement will be updated to reflect them.

Editorial workflow tooling. AI tools and automated accessibility checking continue to evolve. Where workflow tooling improvements happen, the relevant sections will be updated.

Areas of ongoing work. As we resolve current ongoing-work areas (complex tables guidance, cognitive accessibility evaluation, etc.), those areas will move from "ongoing work" to "what works well".

Editorial team responsibility. Adrian writes; Alex reviews; both responsible for accessibility outcomes. This responsibility model is unlikely to change.

Reader engagement valued. Priority routing for accessibility feedback through the corrections process and continuous improvement orientation are foundational to the editorial mission.

UK Equality Act 2010 alignment. As long as the Equality Act 2010 remains the underlying UK accessibility legal framework, alignment will be a core commitment.

Honest documentation orientation. Honest documentation of what works well and where we have ongoing work supports reader trust better than performative claims.

Last updated 28 April 2026. This statement reflects accessibility approach as of April 2026.

Next review within 90 days. As with other v3 trust framework documents, this statement is on the 90-day review cadence with comprehensive review twice yearly.

Communicated through the trust block on every page. Updates to this statement are reflected through the cluster's interconnected trust framework so readers can see when accessibility approach has been updated.