Current status, stated plainly
New experiences should be reviewed before release and after material component changes. Known high-impact barriers should be prioritised by user impact, reach and availability of a workaround. A dated list of unresolved material limitations will be added here when formal testing identifies them.
What the experience is designed to support
Keyboard and focus
All interactive functions should be operable without a pointer, with a logical focus order, visible focus state and a way to bypass repeated navigation.
Screen readers
Pages should use semantic headings, landmarks, labels, status messages and meaningful alternative text rather than visual position alone.
Readable presentation
Text should retain meaning at zoom, reflow on narrow screens, maintain sufficient contrast and avoid colour-only instructions.
Movement and timing
Motion preferences should be respected. Essential time limits require warning and adjustment where feasible; unexpected autoplay should be avoided.
Forms and errors
Inputs need programmatic labels, clear instructions, useful error identification and recovery that does not erase valid work.
Plain decisions
Scores, disclosures and test confidence should be understandable without relying on a badge, icon, chart shape or hover interaction alone.
YouTube, video and non-text content
Original editorial video should include accurate captions. Meaningful visual information needs spoken description, a transcript or an equivalent written explanation where required for understanding. Auto-generated captions should be reviewed for names, technical terms and verdict-changing details.
Embedded YouTube controls are provided by YouTube and can vary by browser and account. A written summary should accompany a video that carries essential review information. If an embed is inaccessible or cannot load, the title and direct destination should remain identifiable.
How accessibility should be tested
- Automated checks for detectable semantics, names, contrast and markup issues.
- Keyboard-only use at common viewport sizes and at high zoom.
- Representative screen-reader checks across at least two major browser/assistive-technology combinations before claiming broad conformance.
- Checks with forced colours, reduced motion, text spacing and mobile orientation changes.
- Usability review by people with disabilities when practical, especially for account, moderation and enterprise workflows.
Automated tools alone cannot establish WCAG conformance. Test scope, dates, pages and unresolved findings should accompany any future conformance statement.
Third-party content
Retailer pages, affiliate destinations, supplied documents and embedded media are not fully controlled by DopeTech. That does not remove the responsibility to choose accessible integrations, provide context and offer a reasonable alternative for essential information. Tell us when a third-party component blocks access so we can investigate an alternative or raise it with the provider.
Enterprise and procurement requests
Customers may request a current accessibility statement, test scope, known-issues register or accessibility roadmap. DopeTech should not provide a VPAT, ACR, certification or conformance claim unless it has been completed against the stated product version by a suitably qualified reviewer.
Report a barrier or request an alternative
Email accessibility@dopetech.au with the page, task, device or assistive technology involved and the format you need. You do not need to disclose a diagnosis. If email is itself a barrier, use any published site contact method and write “Accessibility”.
We aim to acknowledge actionable reports within five business days. This is a service target, not a contractual response guarantee.