Accessibility Statement
Last updated: 26 July 2026
We want everyone to be able to use Your Next Tours, including people who rely on screen readers, keyboard-only navigation, magnification, or reduced motion. We treat WCAG 2.2 Level AA as the standard we are working toward. To be clear about where we stand: this website has not been assessed by an independent auditor, and we do not hold a VPAT or other formal conformance report. What follows is our own honest assessment -- including the parts that fall short.
1. What this statement covers
This statement applies to the yournext.tours website and to the browser-based panel that guides and tour companies sign in to. It describes those two things and nothing else.
It does NOT cover the guide mobile application, nor the participant listening client that is served from the guide's own phone over a local WiFi network during a tour. Those are separate products with different constraints, and we make no accessibility claim about them here.
Parts of the service display content created by other people -- tour templates, itineraries, and company profiles written by guides and tour companies. We do not control that content. We encourage everyone publishing through Your Next Tours to write clear text and to describe their images, but we cannot guarantee that content authored by others is accessible.
2. What we do today
Structure and language: pages are built from semantic HTML with labelled landmarks and navigation. Every page starts with a skip-to-content link, translated into all 26 interface languages. The page language and text direction are always declared, and Arabic and Hebrew are laid out right-to-left using CSS logical properties rather than mirrored hacks.
Keyboard access: there is a visible focus indicator on every focusable element, and we do not remove it anywhere in the interface. Dialogs and the mobile navigation drawer keep focus inside themselves while open, close on Escape, and return focus to the control that opened them. Tab sets built from our shared panel components are operable with the arrow, Home, and End keys. No element is given a positive tab order.
Screen readers: decorative icons are hidden from assistive technology centrally rather than case by case, and no icon-only button is left without a name. Every image carries alt text, with decorative images marked as such. Status and error messages are announced, with errors announced assertively and everything else politely. Data tables declare their header cells.
Motion and colour: if your system asks for reduced motion, we honour it in both our stylesheets and our scripts, so scripted animation never starts. Body text and the large majority of interface colours meet or exceed the AA contrast threshold; body text on white measures about 15:1.
How we keep it from regressing: accessibility linting runs on every push to the panel code, configured slightly stricter than the recommended defaults. The site loads no third-party tracking, no external fonts, and no content delivery networks, which keeps pages simple and predictable for assistive technology.
3. Known limitations
No independent audit. Nothing here has been verified by an external auditor, and we run no automated accessibility test suite and keep no record of screen reader testing. Treat our conformance status as self-assessed and partial, not measured.
Contrast gaps in a few small elements. A small number of items fall below the 4.5:1 threshold for small text: the live status badge, some secondary text sitting on raised panel surfaces, and the version label in the panel sidebar. Increasing your browser or system text size makes these easier to read. We intend to correct them.
Resting borders are low contrast. The outlines of cards and input fields sit below the 3:1 threshold for non-text contrast. Fields do get a clearly visible ring once focused, so this mainly affects telling components apart at rest rather than operating them.
The panel has no skip link and no main landmark. The skip-to-content link and the main landmark exist on the public website but not inside the signed-in panel, which uses a labelled region instead. A screen reader's jump-to-main-content command therefore does nothing in the panel; use the sidebar navigation or heading navigation to move around instead.
The contact form does not explain why it cannot be submitted. Its submit button stays disabled until the required fields are filled, but it does not tell you which field is missing, and it does not mark fields as invalid. If you are stuck, fill in name, email, message, and the consent checkbox -- or skip the form entirely and email us, which we would rather you did than fight the form.
The sign-in screen has two shortcomings. Its fields do not declare their purpose, so password managers will not reliably autofill them; you can still type or paste your details in. And the control that switches between signing in and registering announces itself to screen readers as a tab set without behaving like one -- it does not respond to the arrow keys and is not linked to a labelled panel. It remains fully operable with Tab and Enter.
No dedicated high-contrast mode. Beyond form fields, which are built to keep a visible outline in Windows High Contrast, we have not implemented specific support for forced-colours or increased-contrast preferences. Browser zoom and your own system contrast settings still work.
Charts have a label but no text alternative. The statistics and ratings graphics carry a short description, but there is no equivalent data table or written summary of the trend. The underlying numbers are available elsewhere in the panel, and we will send you the figures if you ask.
Dialogs do not fully isolate the background. When a dialog or the mobile drawer is open we trap keyboard focus, but we do not yet mark the rest of the page as inert. Using a virtual cursor or swipe navigation on iOS VoiceOver or Android TalkBack, you may still reach content behind the dialog.
4. Feedback and contact
If something on this site blocks you, please tell us -- it is the fastest way for us to find and fix problems, and we would rather hear about a barrier than have you work around it silently.
The best route is email: write to [email protected] with the word Accessibility in the subject line, and tell us which page you were on, what you were trying to do, and which browser or assistive technology you use. That detail is what lets us reproduce the problem.
You can also use the contact form on our contact page. It has no subject field, so please start your message with the word Accessibility so it reaches the right people.
We read every report and will reply as soon as we can. We are not setting a fixed response time here, because we do not yet operate a service level commitment and we would rather not promise a deadline we cannot stand behind. We do not publish a phone number for support.
If we cannot resolve something, we will say so plainly and explain the alternative we can offer. This statement is reviewed as the site changes, and the date at the top reflects the last review.