Accessibility Statement

Our Approach

Access Tours is built using WCAG 2.2 AA guidelines for the viewer user interface and its integration with Google Street View. We apply recognised accessibility principles throughout our design and development.

This statement describes our accessibility features and internal self-assessment. Access Tours has not been independently third-party audited. We do not claim certified conformance to any standard. The underlying Google Street View imagery is third-party content and is beyond our control.

We test internally using automated and manual methods. Access Tours provides voiceover narration, synchronised captions, full keyboard navigation, and structured scene descriptions as accessible alternatives to the panorama canvas itself.

Scope of Accessibility Features

In scope (features we've built and tested)

• Access Tours viewer UI — toolbar, panels (settings, help, scenes, points of interest), captions, status indicators
• Keyboard navigation — arrow keys, Page Up/Down, Home/End, letter shortcuts, Escape, Tab focus cycling, focus traps on dialogs
• Voiceover narration and synchronised captions (Web Speech API)
• Visual accessibility settings — high contrast, greyscale, invert colours, text size, line height, letter spacing, dyslexia-friendly font, large cursor, reading guide, focus highlight, reduced motion support
• Point of interest markers, descriptions, and accessible labelling
• Voice navigation via speech recognition with capability detection for unsupported browsers
• Flat (equirectangular) panorama view with keyboard-accessible pan controls
• Live region announcements for status updates and errors
• Host viewer page and iframe-embed accessibility model

Out of scope (third-party content)

• Google Street View panorama imagery and rendering — this is third-party content served by Google
• Google's native controls and attribution — these are Google's responsibility
• Web Speech API voice quality and recognition accuracy — these vary by browser and operating system
• Operating-system assistive technologies — these are the responsibility of the OS vendor

WCAG 2.2 AA Success Criteria

The following success criteria received specific design and testing attention:

• 1.1.1 Non-text Content — all controls are labelled with aria-label; panorama scenes have AI-generated descriptions
• 1.3.1 Info and Relationships — semantic landmarks, dialog roles, and live regions structure the interface
• 1.4.3 Contrast (Minimum) — automated testing verifies 4.5:1 contrast on text, 3:1 on graphical elements
• 1.4.4 Resize Text — text-size controls scale viewer typography without loss of functionality
• 1.4.10 Reflow — layout adapts to narrow viewports without horizontal scroll
• 2.1.1 Keyboard — every control is reachable via keyboard; Tab navigation verified across all UI states
• 2.1.2 No Keyboard Trap — Escape exits every dialog; focus management is tested on every interaction
• 2.4.3 Focus Order — Tab cycles logically within dialogs and returns to the trigger button on close
• 2.4.7 Focus Visible — explicit focus rings on all interactive elements
• 2.5.7 Dragging Movements — panorama pan and zoom have button alternatives in the toolbar
• 2.5.8 Target Size (Minimum) — toolbar buttons are 36px or larger
• 3.3.1 Error Identification — errors are announced via accessible alerts
• 4.1.2 Name, Role, Value — semantic HTML and ARIA provide name, role, and state to assistive technologies
• 4.1.3 Status Messages — live regions announce status changes and errors

Testing

We perform layered internal testing:

• Automated accessibility scans using industry-standard tools across multiple UI states; current result: zero critical violations
• Keyboard navigation tests — Tab traversal and focus management verified across every panel and dialog
• Screen reader testing — VoiceOver (macOS) and NVDA (Windows) walkthrough of key user flows
• Visual testing — contrast, text resizing, and reduced-motion support verified
• Regression testing — automated tests run on every code change to catch accessibility regressions early

Last updated: 2 July 2026

Known Limitations

• The Google Street View panorama is third-party content rendered in Google's WebGL canvas. We cannot guarantee its accessibility properties. Access Tours provides keyboard and voiceover alternatives to mitigate this.
• Web Speech API quality varies by browser and operating system. We disable speech features on browsers that don't support them, rather than offering broken functionality.
• Touch gesture support follows common accessibility patterns. Very small devices or unusual screen sizes may have edge cases.

Standards and Resources

• WCAG 2.2 Quick Reference at W3C WAI
• ARIA: Accessible Rich Internet Applications
• Accessibility Australia Resources