Accessibility Statement

1. Our commitment

SuperStation95 aims to be usable by as many people as possible, including people using screen readers, keyboard navigation, magnification, voice control, or reduced motion settings. Accessibility is treated as part of editorial and design quality rather than as a separate project bolted on at the end, which means it is considered when a page is planned, not only when it is tested.

Travel information is disproportionately important to people who face physical, sensory, or cognitive barriers, because the cost of an inaccurate or unusable page is higher when a reader has fewer alternative sources or less flexibility to adapt on the day of travel. We take that responsibility seriously and treat accessibility reports as a priority category of feedback.

2. Conformance target and current status

We work towards the Web Content Accessibility Guidelines version 2.2, level AA, published by the W3C Web Accessibility Initiative. This is the target we design and build against, not a formal third party certification, and our current status is best described as partially conformant, meaning most content and functionality meets the standard but some areas identified below have not yet been fully verified or remediated.

We moved our internal target from WCAG 2.1 to WCAG 2.2 as the newer version was published, and we are working through the additional success criteria it introduces, such as clearer requirements around focus visibility and target size, as part of our normal page review cycle rather than as a separate one-off project.

A page that has been reviewed and found compliant can still regress if a later content or design change is made without accessibility in mind, which is why review is treated as ongoing rather than a one time exercise.

3. How we test

• Keyboard testing: navigating an entire page using only the keyboard, checking that every interactive element can be reached, activated, and escaped, and that the visible focus indicator never disappears.
• Screen reader testing: reading through key pages with a screen reader active, checking that headings, landmarks, links, and form fields are announced in a sensible and predictable order.
• Zoom testing: viewing pages at 200 percent browser zoom, and separately at higher operating system text scaling, to confirm that text does not overlap, get clipped, or require horizontal scrolling to read.
• Contrast testing: checking body text, links, and interface elements such as buttons and form fields against the AA contrast thresholds using automated contrast checking tools, followed by a manual visual check.
• Automated scanning: running automated accessibility scanning tools during development to catch common structural issues early, understanding that automated tools only catch a portion of possible problems and cannot replace manual review.

4. Assistive technologies we test with

• NVDA and JAWS screen readers on Windows, using recent versions of Chrome and Firefox.
• VoiceOver on macOS and iOS, using recent versions of Safari.
• TalkBack on Android, using recent versions of Chrome.
• Keyboard-only navigation without a mouse or trackpad, across all major desktop browsers.
• Browser-level zoom up to 400 percent and operating system level text scaling.
• High contrast and reduced motion operating system settings.
• Voice control software for hands-free navigation on the pages we consider highest traffic.

5. What we do

• Semantic HTML with a single main heading per page and a logical, non-skipping heading order.
• Descriptive alternative text on editorial imagery, and empty alternative text on purely decorative images so screen readers do not announce them unnecessarily.
• Colour contrast checked against AA thresholds for body text, links, and interface elements such as buttons and form fields.
• Visible keyboard focus indicators on every interactive element, not suppressed by custom styling.
• Forms with real associated labels rather than placeholder text alone, plus clear error messages tied to the relevant field.
• Layouts that reflow to 320 pixels wide without horizontal scrolling or loss of content.
• Skip links and consistent navigation structure repeated in the same relative order on every page.

6. Accessibility of images and documents

Editorial photographs carry alternative text describing their content where that content adds meaning beyond the surrounding article, and purely decorative images are marked so assistive technology skips over them. Reference tables and figures are built with real table markup and header cells rather than as images of tables, so their content can be read row by row rather than being invisible or unreadable to a screen reader.

We avoid publishing key travel information only as a downloadable document. Where a document such as a printable checklist is offered as a supplement to an article, the same information is also available as accessible text on the page itself, so no reader depends on the document being accessible to get the information.

7. Known limitations

• Some photographs carry descriptive captions that repeat information already available in the surrounding article text, which can feel redundant to screen reader users, and we are working through older articles to tighten this.
• Third party embeds, including any future map, video, or search widget, may not fully meet our standard until they have been individually reviewed, since we do not control the underlying code of embedded third party tools.
• Long reference tables, such as baggage or fee comparison tables, can be demanding to navigate on very small screens or with certain screen reader table modes, and we are evaluating simplified alternative presentations.
• Some older archived pages predate our current accessibility checklist and have not yet been fully retested against it.
• A small number of interactive elements have touch targets smaller than the size recommended by WCAG 2.2, and these are being adjusted as pages are revised.

8. Third party content

Where an article links to or embeds content hosted by a third party, such as an airline's own fare rules page or an official tourism board resource, that content is outside our control and may not meet the same accessibility standard we apply to our own pages. We choose reputable, mainstream providers where a choice exists, and we note in the article itself if a linked resource is known to have significant accessibility problems.

9. Reporting a barrier and response time

If something on this site is difficult or impossible to use, tell us through the contact page or by phone on +1 251-355-0231. Include the page address, a description of the problem, and the assistive technology and browser you were using, since that helps us reproduce the issue quickly.

Accessibility reports are treated as a priority category of feedback. We aim to acknowledge receipt within two business days and to provide either a fix, a workaround, or a realistic timeline for resolution within ten business days of acknowledgment. If a fix will take longer, we will tell you why and keep you updated.

10. Alternative formats

If you need an article in a different format because the standard page layout does not work for you, ask through the contact page and we will provide a plain text or large print version where we reasonably can, at no charge.

11. Formal complaints and further steps

This statement describes our own effort and is not a guarantee of full conformance. If you have raised a barrier with us and are not satisfied with the response or the timeline given, you can ask for the matter to be escalated within our team by referencing your original report when you write back.

If, after that, you still feel the matter has not been resolved appropriately, you may be able to raise it with a relevant regulator or accessibility body in your jurisdiction, depending on where you are located and the nature of the barrier you encountered. We would rather resolve a problem directly, and we take a request to escalate a matter as a signal that we need to move faster, not as something to be defensive about.