Accessibility statement

Effective October 1, 2026. Zenith aims to make its editorial site usable by people with different abilities, devices, browsers, and connection speeds.

1. Our approach

We use semantic headings, readable contrast, descriptive alternative text, keyboard-accessible controls, and responsive layouts. We avoid making colour the only way to understand information. Public content is reviewed as the site develops. A concrete example is the use of proper heading levels, such as a single h1 per page followed by nested h2 subsections, which allows a screen-reader user to jump directly between sections rather than reading an entire article linearly. The practical consequence of responsive layouts is that an article remains readable whether opened on a small phone screen in variable mobile network conditions or on a larger desktop display, without requiring horizontal scrolling or illegibly small text. An edge case involves older browsers that do not fully support modern responsive techniques; in that situation, content still degrades to a readable, if less polished, linear layout rather than becoming inaccessible outright.

a) Proper heading hierarchy allows screen-reader users to navigate directly between sections rather than reading linearly.
b) Responsive layouts are designed to remain usable across a wide range of screen sizes and network conditions common in Indonesia.
c) Older or less capable browsers receive a simplified but still readable fallback layout rather than a broken page.

This approach is informed by the Web Content Accessibility Guidelines (WCAG) 2.1, used here as a general reference point for reasonable practice rather than as a formal certification claim, given that Zenith is an independent editorial publication rather than a government or regulated service provider.

2. Images

Images include descriptive alternative text when they convey information. Decorative imagery is treated differently where appropriate. Text is not placed over busy photos. We welcome reports where an image description is unclear. A concrete example is a photograph illustrating a specific exercise form, where the alternative text describes the posture and equipment shown so a screen-reader user receives the same practical information a sighted reader would get visually. The practical consequence of keeping text off busy photo backgrounds is improved contrast and readability for every reader, not only those using assistive technology, since overlaid text on a complex image is a common source of general legibility complaints. An edge case involves purely decorative imagery, such as a background texture with no informational content; in that situation alternative text is either omitted or marked as decorative so assistive technology does not waste a reader's attention on describing something that carries no meaning.

a) Alternative text for instructional photos describes posture, equipment, and context relevant to the article.
b) Avoiding overlaid text on busy photo backgrounds benefits general legibility, not only assistive-technology users.
c) Purely decorative images are marked so they do not interrupt a screen-reader user's attention unnecessarily.

3. Keyboard use

Navigation and forms should be reachable without a mouse. Focus indicators help readers understand location. The mobile menu uses a labelled control. Report any keyboard trap with the page address and browser. A concrete example is tabbing through the main navigation menu and the contact form fields in a logical order using only the keyboard's Tab key, with a visible outline indicating which element currently has focus. The practical consequence of a labelled mobile menu control is that a keyboard or screen-reader user can identify and activate the menu toggle without relying on a visual hamburger icon alone. An edge case is a so-called keyboard trap, where focus becomes stuck inside a component and cannot be moved forward or backward using standard keys; this is treated as a priority defect, and reports including the exact page and browser help us reproduce and resolve it quickly.

a) Logical tab order across navigation and form fields is maintained so keyboard-only use remains practical.
b) The mobile menu control carries a text label readable by assistive technology, not only a visual icon.
c) Reported keyboard traps are treated as priority defects requiring prompt investigation and a fix.

4. Content

Headings are arranged to support scanning and screen-reader navigation. Tables include meaningful headers. Links describe their destinations. Long articles use lists and short paragraphs where this improves comprehension. A concrete example is a comparison table, such as one contrasting different training approaches, where each column has a clear header cell identified in markup so a screen-reader user hears the column label before each data value rather than a disconnected list of numbers. The practical consequence of descriptive link text is that a reader scanning only the links on a page, a common assistive-technology navigation pattern, can understand each destination without needing the surrounding sentence for context. An edge case involves necessarily long, detail-heavy articles, such as in-depth physiology explanations; in that situation lists and subheadings are used deliberately to break the material into scannable chunks rather than presenting it as one unbroken block of text.

a) Table header cells are marked in a way that associates each data value with its column label for screen-reader users.
b) Link text describes the destination directly, supporting link-only scanning as a navigation pattern.
c) Long technical articles are broken into lists and subheadings to remain scannable rather than left as one dense block.

Comparison tables in particular, such as the ones used on the Guide and Glossary pages, are built with a single clear header row rather than merged or nested header cells, since overly complex table structures are a common source of confusion for assistive-technology users even when visually they appear straightforward.

5. Motion

The site avoids unnecessary animation and does not require motion to access editorial content. Browser settings may also reduce motion. If an interaction causes discomfort, contact us so we can review it. Static alternatives are preferred for important information. A concrete example is the mobile navigation menu opening with a simple, brief transition rather than an elaborate animated sequence, so readers sensitive to motion are not required to watch a prolonged effect just to reach the menu items. The practical consequence of respecting browser-level reduced-motion settings is that a reader who has configured their operating system to minimise animation will experience a calmer version of the site automatically, without needing a separate Zenith-specific setting. An edge case involves any future interactive feature that might rely more heavily on animation, such as an illustrated training sequence; before introducing such a feature we would plan a static fallback consistent with this section's stated preference.

a) Navigation transitions are kept brief and simple rather than elaborate or prolonged.
b) Operating-system-level reduced-motion settings are respected automatically where the browser communicates that preference.
c) Any future animation-heavy feature would be planned with a static fallback consistent with this section.

6. Forms

Contact fields have visible labels and required fields are identified by browser validation. Messages should not include unnecessary sensitive data. A successful submission message is displayed after the form action. Contact us if a field is difficult to complete. A concrete example is the name, email, and message fields on the Contact page, each carrying a visible text label rather than relying solely on placeholder text that disappears once typing begins, since disappearing placeholder-only labels are a known accessibility and general usability weakness. The practical consequence of the required-field validation is that a reader is told clearly, before submission completes, if a mandatory field such as email has been left empty, avoiding a confusing silent failure. An edge case involves a reader using voice-input software to complete the form; visible, persistent labels make it easier for that reader to confirm which field they are dictating into, compared with placeholder-only designs that can disappear once input begins.

a) Visible, persistent field labels are used instead of relying solely on disappearing placeholder text.
b) Required-field validation gives clear feedback before submission completes rather than failing silently.
c) Voice-input users benefit from persistent labels that remain visible while dictating into a field.

7. Assistive technology

We test common combinations but cannot cover every device. Differences may arise from browser extensions, reader settings, or third-party software. Include your setup in a report where possible. We will use the information to improve practical access. A concrete example of a common combination tested is a modern screen reader paired with a current version of a mainstream browser, representing a large share of assistive-technology users likely to visit an editorial health and fitness site. The practical consequence of the wide variety of possible setups is that an issue experienced by one reader on an older device or an uncommon browser extension combination might not surface during our own routine testing until specifically reported. An edge case involves conflicting behaviour between two different assistive tools used simultaneously, for example a screen reader alongside a separate browser magnification extension; in that situation isolating which tool is responsible for an issue often requires back-and-forth with the reporting reader, which is why detailed setup information is so valuable.

a) Testing focuses on common, high-usage combinations of browser and assistive technology.
b) Less common setups, including specific extensions, may surface issues only through direct reader reports.
c) Conflicting behaviour between multiple simultaneous assistive tools may require detailed back-and-forth to properly diagnose.

8. Feedback

Send accessibility feedback through Contact or call +62 812 7384 5901. Include the page, barrier, and preferred contact method. We aim to acknowledge feedback within five working days. We do not require a diagnosis or proof of disability. A concrete example of a well-formed report is a message naming the Recovery page, describing that a particular image lacks a clear description, and noting a preferred reply method such as email. The practical consequence of not requiring proof of disability is that any reader encountering a barrier, whether or not they identify as disabled, can report it and have it reviewed on the same basis. An edge case involves feedback submitted by phone rather than through the Contact form; phone reports are logged with the same page, barrier, and contact-preference details as written ones, consistent with the approach described in the Privacy policy for handling complaints received by different channels.

a) Reports naming a specific page and barrier are the most actionable and quickest to investigate.
b) No proof or disclosure of a specific disability is required to have a reported barrier reviewed.
c) Phone-based reports are logged with the same detail as written ones to ensure consistent follow-up.

We acknowledge that a small, editorially focused team cannot resolve every reported barrier immediately, and we would rather tell a reader honestly that a fix is scheduled for a later date than overstate progress on a report still under investigation.

9. Alternatives

If a page is difficult to use, contact us for help locating the information. We may provide a plain-text explanation or clarify a section. This is not a promise of a particular format. We will still investigate the underlying barrier. A concrete example is a reader struggling with a complex comparison table who contacts us for a plain-language summary of the same information while we separately investigate improving the table's own accessibility. The practical consequence of treating this as an interim measure rather than a permanent substitute is that we aim to fix the underlying barrier for future readers, not only to work around it for the one reader who reported it. An edge case involves a request for a format we are not able to readily produce, such as a specific specialised document type; in that situation we will explain what we can offer instead and continue investigating the original barrier regardless.

a) Interim plain-text or verbal explanations are offered as a bridge while the underlying barrier is investigated.
b) Fixing the root cause for future readers remains the goal, not only resolving a single reported instance.
c) Where a specific requested format cannot be produced, an available alternative is offered while the investigation continues.

10. Review

This statement was published October 1, 2026. We review accessibility when templates or major content areas change. The next internal review is planned for April 2027. Updates will show their effective date. A concrete example of a trigger for an interim review, ahead of the scheduled April 2027 date, would be a substantial redesign of the main navigation or the introduction of a new interactive feature such as a comments system. The practical consequence of a scheduled review date is that even in the absence of a major redesign, accessibility practices are revisited on a predictable cycle rather than only reactively after a complaint. An edge case involves feedback received shortly before the scheduled review; such feedback is folded into the April 2027 review process directly, in addition to being acknowledged individually under Section 8's five-working-day target.

a) Major template or navigation redesigns trigger an accessibility review independent of the scheduled date.
b) The scheduled April 2027 review ensures a predictable cycle even without a specific triggering complaint.
c) Feedback received shortly before a scheduled review is incorporated into that review in addition to its individual acknowledgment.