Accessibility Statement

1. Our Commitment#

Slash Tech Australia Pty Ltd is committed to providing digital experiences that are accessible and inclusive for everyone, including people with disabilities. We design, build, and test our website and platforms to meet WCAG 2.2 Level A and work toward progressively higher conformance over time.

Accessibility is treated as an ongoing discipline, not a checklist. We embed it into how we design, build, and test — and we hold our client work to the same standard.

2. Standards & Scope#

Standards. This statement references the Web Content Accessibility Guidelines (WCAG) 2.2, published by the World Wide Web Consortium (W3C). Our conformance target is Level A.

Scope. This statement applies to:

• The Slash Tech public website at slashtech.com.au
• Client-facing dashboards and SaaS platforms operated by Slash Tech
• Documentation and resources published by Slash Tech

Exclusions. The following are not covered by this statement:

• Third-party services, widgets, and embeds where we do not control the underlying markup (for example, embedded booking tools or payment providers)
• Client-operated systems where Slash Tech does not retain ongoing control
• Archived content published before our current accessibility baseline was established

Where third-party integrations present known barriers, we document them in our Known Limitations section and seek alternatives where practicable.

3. Design & Build Practices#

We integrate accessibility into our process at each stage:

Semantic markup. We use native HTML elements for their intended purpose — headings to communicate structure, buttons for actions, links for navigation, and landmark roles to orient screen reader users. We avoid using <div> or <span> where a native element would be more appropriate.

Colour contrast. We aim to meet the WCAG 2.2 Level A contrast requirements for text and UI controls. Colour is never the sole means of conveying information.

Focus management. Interactive elements have visible focus indicators. Focus order follows logical reading order. Modals and dialogs trap focus correctly and return focus to the triggering element on close.

Responsive layouts. Content reflows at 320px viewport widths without horizontal scrolling. We do not use fixed pixel font sizes.

ARIA use. ARIA attributes are used to supplement — not replace — native HTML semantics. We use aria-label, aria-expanded, aria-haspopup, aria-current, and aria-live where appropriate for custom components.

Reduced motion. Animations respect the prefers-reduced-motion media query. Decorative motion is suppressed for users who have enabled this preference in their operating system.

4. Testing & Verification#

We test for accessibility using a combination of automated and manual methods:

Automated scanning. We use browser-native audit tools and Axe to identify common violations during development. Automated tools catch a subset of issues; they are a starting point, not a complete check.

Manual keyboard testing. We verify that all interactive functionality can be operated using a keyboard alone, without requiring a mouse or pointer device.

Screen reader spot-checks. We conduct periodic checks using VoiceOver on macOS/iOS and NVDA on Windows to verify that key flows are correctly announced.

Review during development. Accessibility review is part of our standard front-end code review process.

5. Assistive Technology Support#

We test and aim to support the following assistive technologies:

If you use assistive technology not listed here and encounter a barrier, please let us know — we investigate all reported issues.

6. Keyboard & Interaction#

All interactive functionality on Slash Tech properties is operable by keyboard. Specifically:

• Every interactive element is reachable by pressing Tab (forward) and Shift+Tab (backward)
• A Skip to main content link is the first focusable element on every page
• Dropdown menus, dialogs, and disclosure widgets can be closed using the Escape key
• No keyboard traps exist — a user can always navigate away from any component using standard keyboard controls

7. Media & Documents#

Images. All informative images have descriptive alt text. Decorative images have empty alt="" attributes so screen readers skip them.

Video and audio. We do not use auto-playing audio or video. Where we publish video with meaningful audio, captions are provided.

Documents. If you need an accessible version of any document we publish, contact us and we will provide one.

8. Compatibility & Performance#

Browser support. Our properties are tested on the two most recent stable versions of Chrome, Firefox, Safari, and Edge.

Performance. We apply lazy loading, appropriate image sizing, and minimal blocking scripts to keep load times reasonable for users on slower connections or assistive devices.

Touch targets. Interactive targets are sized to meet the WCAG 2.2 Level A minimum of 24×24 CSS pixels, with adequate spacing between them.

9. Known Limitations#

We are committed to transparency about where our accessibility falls short. The following known issues are being actively tracked:

• Embedded booking widget: Our Microsoft Bookings integration is a third-party embed. We do not control its markup. Users who experience barriers with this widget should contact us directly at contact@slashtech.com.au to arrange an alternative booking method.
• PDF documents: Older PDF documents may not be fully tagged for assistive technology. We review and update these on an ongoing basis. Contact us if you need an accessible version.

We publish this list in good faith. If you discover an issue not listed here, please report it — we treat accessibility reports as priority bugs.

10. Feedback & Contact#

If you experience an accessibility barrier on any Slash Tech property, we want to hear about it.

Email: contact@slashtech.com.au

Contact form: slashtech.com.au/contact

Address: Unit 12/783 Kingsford Smith Drive, Eagle Farm QLD 4009, Brisbane QLD Australia

When reporting an issue, please include:

• The URL or name of the page or feature affected
• The assistive technology and browser you are using (if applicable)
• A description of what you expected to happen and what actually happened

We aim to acknowledge accessibility reports within two (2) business days and to provide a substantive response or a workaround within five (5) business days. For issues requiring development work, we will provide a target remediation date.

If you are unsatisfied with our response, you may contact the Australian Human Rights Commission regarding obligations under the Disability Discrimination Act 1992.

11. Continuous Improvement#

Accessibility is not a state we reach — it is a practice we maintain. Our ongoing commitments include:

• Reviewing this statement at least annually and updating it to reflect the current state of our properties
• Including Level A requirements in design reviews and code review for all new front-end work
• Remediating reported issues according to severity, with blocking barriers prioritised within a sprint
• Progressively working toward Level AA conformance where practicable

This statement was last reviewed on 26 May 2026. The next scheduled review is 26 May 2027.