Valour.

Accessibility statement

We approach accessibility as an ongoing editorial and technical responsibility rather than a one-time checklist completed and forgotten, because new articles, images and interactive elements are added regularly and each one needs to meet the same basic standard. A reader relying on a screen reader, a reader navigating primarily by keyboard due to a motor condition, and a reader simply using a smaller or older device each benefit from many of the same underlying choices, such as clear heading structure and sufficient colour contrast, even though their specific needs differ. We treat accessibility improvements as part of normal site maintenance, reviewed whenever we update our shared templates, add a new page type, or receive feedback indicating a specific barrier. This statement describes our current approach and known limitations honestly, rather than claiming a level of perfection we have not independently verified through formal testing. Where we fall short of our own stated aim on a specific page, we would rather hear about it and fix it than have a reader assume the gap was intentional.

  1. Our aim

    Clear headings, meaningful links, readable contrast and keyboard access are our baseline goals across the site. Clear headings means using a single, descriptive page title and a logical hierarchy of subheadings beneath it, so a reader using assistive technology to jump between headings can understand an article's structure without reading every word first. Meaningful links means avoiding vague link text such as "click here" in favour of text that describes the destination, for example a link reading "read our sleep guidance" rather than an unlabelled "more". Readable contrast means choosing text and background colour combinations, such as our charcoal text on a cream background, that remain legible for readers with low vision or colour-vision differences, which we check against commonly referenced contrast guidelines during design work. Keyboard access means that a reader who cannot or does not use a mouse should still be able to reach every interactive element, including navigation links and the contact form, using the tab key and standard keyboard commands.

    • Heading hierarchy: one h1 per page, logically nested h2/h3 beneath it.
    • Link text: descriptive rather than generic phrases like "click here".
    • Contrast: checked against commonly referenced guidance for text-background colour pairs.

  2. Structure

    Semantic landmarks, ordered headings and labels for form controls are used throughout the site. Semantic landmarks refer to using HTML elements such as a header, main content area, navigation region and footer that are specifically intended for those roles, because assistive technology relies on these landmarks to let a reader jump directly to, for example, the main article content while skipping repeated navigation. Ordered headings means every page follows a single top-level heading followed by appropriately nested subheadings, avoiding the common error of skipping a level or using a heading purely for visual size rather than genuine structural meaning. Labels for form controls means that, on our contact form, each input field is associated with a visible, descriptive label rather than relying solely on placeholder text, which can disappear once a reader starts typing. We test our primary templates, such as the article layout and the contact form, more thoroughly than one-off page elements, since templates affect the largest number of pages at once.

    • Semantic landmarks: header, main, navigation and footer regions marked up for their actual role.
    • Heading order: no skipped levels, no heading used purely for visual size.
    • Form labels: visible, descriptive labels rather than placeholder text alone.

  3. Images

    Informational images include descriptive alternative text. Purely decorative elements are marked so assistive technology can skip them. Descriptive alternative text means that an image used to illustrate an article includes a written description conveying what the image shows and why it is relevant, so a reader using a screen reader receives equivalent information to a sighted reader glancing at the photo. We aim to keep alternative text specific and genuinely descriptive rather than generic, avoiding unhelpful text such as "image" or "photo" that provides no real information about the image's content. We avoid using an image as the sole way to convey information that should be in the main text; key statistics are described in the surrounding paragraph, not only inside a graphic. When we review an older article for other reasons, checking and improving its image descriptions is a routine part of that review.

    • Informational images: specific, descriptive alternative text matching the image's actual content and relevance.
    • Decorative elements: marked to be skipped by assistive technology rather than narrated.
    • Key information is never conveyed solely through an image with no text equivalent.

  4. Keyboard use

    Navigation, articles and the contact form can be operated without a mouse. This means a reader should be able to reach the main navigation menu, every article link, the contact form fields and the submit button using only the tab key to move forward and shift-tab to move backward, without needing a mouse at any point. Focus visibility means that as a reader tabs through interactive elements, there is a clearly visible indicator, such as an outline or highlight, showing exactly which element is currently selected, which is essential for understanding where they are on the page. We treat a missing or faint focus indicator as a genuine defect to be corrected, not a minor cosmetic preference, because without it keyboard navigation becomes effectively unusable even if every element is technically reachable. If a reader ever finds an interactive element that a mouse can reach but a keyboard cannot, that is exactly the kind of specific, actionable report we most want to receive through the feedback channel below.

    • Full reachability: every interactive element accessible via tab and shift-tab alone.
    • Visible focus indicator: a clear outline or highlight on the currently selected element at all times.
    • Mobile menu: opening, closing and navigating within it verified to work via keyboard.

  5. Language

    Content is published in clear English with plain explanations of medical terms. Publishing in English as our single working language allows us to maintain one consistent, carefully reviewed version of each article rather than spreading editorial attention across multiple translations we could not review as thoroughly, though we recognise this is a limitation for a reader more comfortable in another language. We write with deliberately plain explanations of health and medical terminology, generally defining a technical term in ordinary language the first time it appears in an article rather than assuming prior familiarity with clinical vocabulary. Readers are welcome to use a browser's built-in translation feature to read Valour in another language, understanding that any such translation is generated by that external tool and its accuracy is outside our control. We have not identified a specific reader need that would justify maintaining fully separate translated versions of the site at this time, but we would reconsider this if reader feedback indicated a clear and sustained need.

    • Single working language (English), reviewed carefully rather than spread across multiple unreviewed translations.
    • Technical and medical terms generally explained in plain language on first use.
    • Browser or third-party translation tools are a reader's own choice, with accuracy outside Valour's control.

  6. Limitations

    Older browsers, some third-party embeds and occasional content gaps may not fully meet our aim. An older browser and operating system combination may not render our templates exactly as intended, and while we test against commonly used current browsers, we cannot practically test every historical combination still in use by a small number of readers. A third-party embed, where one exists in an article, is accessible only to the extent that the third party itself has built accessible functionality into its own product, which is outside our direct control. Newly published content occasionally contains a small accessibility gap despite our review process, simply because human review is not infallible even when conducted carefully. We would rather acknowledge a known limitation honestly in this statement than imply a level of accessibility perfection that ongoing testing has not actually confirmed.

    • Older browser or OS combinations may render imperfectly despite testing on current common browsers.
    • Third-party embedded content is only as accessible as the embedding provider has made it.
    • Newly published content occasionally contains a minor gap corrected upon review or report.

  7. Feedback

    Report a barrier through contact.php or by phone at +62 813 6789 2468. A useful accessibility report typically includes the specific page address or article title, the device and browser you were using, any assistive technology involved, and a clear description of what happened versus what you expected to happen. We treat an accessibility report with the same seriousness as a factual correction request, logging it, assigning it for review, and tracking it through to a resolution or a clear explanation of why a particular fix is not currently feasible. If you are comfortable providing a way to follow up, we will let you know once the specific issue you reported has been addressed, though this follow-up is not guaranteed for every report depending on volume. We welcome a report even if you are not entirely sure whether something is a genuine accessibility barrier or simply a preference, since the distinction is sometimes genuinely unclear.

    • Helpful detail: page, device, browser, assistive technology used, and expected versus actual behaviour.
    • Two channels: contact.php for written detail, or +62 813 6789 2468 for a verbal description.
    • Reports are logged and tracked, with follow-up offered where contact detail is provided.

  8. Response

    We aim to acknowledge a report within 10 business days. Ten business days is our target for an initial acknowledgement, meaning a response confirming we have received the report and understood the issue, not necessarily a completed fix within that window, since some fixes require template changes that take longer to implement and test properly. For a straightforward issue, such as a single missing image description, we aim to resolve it considerably faster than the ten-day acknowledgement target. For a more structural issue, such as a keyboard-navigation problem within a shared template affecting many pages at once, resolution may take longer, and we will explain the expected timeframe once we have assessed the scope of the needed change. We track every accessibility report to a documented outcome internally, even where the outcome is that a particular technical constraint could not be fully resolved within the current platform.

    • Acknowledgement target: within 10 business days of a report being received.
    • Simple fixes: often resolved faster than the acknowledgement target itself.
    • Structural fixes: may take longer, with an explained timeframe once scope is assessed.

  9. Standards

    We take general direction from recognised web accessibility guidance (WCAG principles). The WCAG framework organises accessibility around four principles: content must be perceivable through at least one sense even if another is unavailable, operable using different input methods including keyboard alone, understandable in its structure and language, and robust enough to work reliably across different assistive technologies and browsers. We treat WCAG as a directional reference informing our practical choices rather than claiming formal certification against a specific conformance level, since we have not undergone independent, formal conformance auditing at this time. Where a specific guideline conflicts with a genuine editorial need, for example a complex data table that is difficult to simplify without losing meaning, we try to find the most accessible practical solution available rather than abandoning the content entirely. This section should be read as a statement of informed direction and intent, not a formal compliance certificate.

    • Perceivable: content available through at least one sense, with text alternatives for non-text content.
    • Operable: full functionality available without requiring a mouse.
    • Understandable and robust: consistent structure, plain language and compatibility across common assistive technologies.

  10. Review

    This statement is reviewed when templates change materially and at least once a year. A significant template change, for example a redesign of our article layout or navigation menu, automatically triggers a fresh accessibility review of the affected components before the change is published broadly. We also plan a routine review of this statement at least once a year, independent of any specific triggering change, simply to confirm it still accurately describes our current practice. Feedback received through the channel described above directly informs the priorities for each review cycle, meaning a frequently reported issue is more likely to be addressed in the next scheduled review than an issue nobody has flagged. The date associated with this statement reflects when it was last substantively reviewed and updated, and we intend to keep that date current rather than static.

    • Significant template or navigation changes trigger an immediate, targeted accessibility review.
    • A routine annual review checks the statement's continued accuracy even without a specific trigger.
    • Reader-reported issues directly inform what is prioritised in the next review cycle.