Accessibility statement
Reviewed 1 October 2026. Kleven aims to make editorial information readable and usable across common devices, browsers, and assistive technologies. We treat accessibility as an ongoing practice rather than a one-time label. For example, a template update to the navigation menu triggers a fresh check of keyboard behaviour and heading order before it is published site-wide, rather than relying on how the previous version performed. This statement covers every page published under the Kleven domain, including the long-form articles under nutrition, movement, sleep, stress, hormones, relationships, and prevention, as well as the policy pages such as this one. We generally aim to align our practice with the WCAG 2.1 Level AA guidelines as a working reference point, while recognising that full conformance is a continuous process rather than a fixed achievement. Where a specific page falls short of this aim, we would rather hear about it through the feedback channel below than have a reader assume the gap is permanent.
1. Our approach
We use semantic headings, descriptive link text, keyboard-friendly controls, visible focus treatment, readable contrast, and responsive layouts. We avoid using colour alone to communicate meaning. Images include descriptive alternative text when they convey information. For example, a photograph illustrating a walking routine in a movement article carries alternative text describing the setting and activity shown, such as a man walking along a tree-lined path, so a screen reader user receives the same contextual information as a sighted reader. Keyboard focus is styled with a visible outline so a reader navigating by tab key can always tell which link or button is currently selected, rather than needing to guess. Colour is never the only signal for an interactive state, so a link is also underlined or otherwise distinguished from plain text beyond colour alone. We test major layout templates, including the header, footer, and article body, across at least two current browser engines before they are rolled out across the site.
2. Content structure
Pages use headings to create a navigable outline and lists or tables where those structures clarify information. Long policy pages are divided into numbered sections. Readers may use browser zoom and text settings without needing a separate mobile site. For example, increasing browser zoom to 200 percent on an article page should reflow the text into a single readable column rather than causing content to overlap or disappear off the edge of the screen. We use a single responsive layout rather than a separate stripped-down mobile version, which means a reader using assistive technology on a phone encounters the same heading structure and content order as a reader on a desktop computer. Tables, such as the comparison table on the homepage, include header cells marked so that a screen reader can announce row and column context rather than reading values as an unstructured list. Numbered policy sections, like the ones on this page, use a consistent heading level so a reader can jump between sections using a screen reader's heading navigation feature.
3. Forms
Contact fields have visible labels and required fields are identified by the browser. A successful submission message appears after the form is sent. We do not request medical records through the general form and encourage concise, relevant messages. For example, the name, email, and message fields on contact.php each carry a visible text label positioned above the field rather than relying solely on placeholder text, which can disappear once typing begins and confuse a screen reader user about what was asked. Required fields are marked both visually and in the underlying markup, so a reader using assistive technology is told which fields must be completed before the browser will allow submission. Error messages, such as an improperly formatted email address, are presented as text near the relevant field rather than only as a colour change, so the issue is clear regardless of how the reader perceives colour. After a successful submission the confirmation message is presented prominently on the page so it is not missed by a reader who has already moved focus elsewhere.
4. Keyboard use
Navigation, links, buttons, disclosure elements, and form controls are intended to work with a keyboard. Focus indicators may vary by browser settings but should remain visible. If a control cannot be reached or understood, please report its page and device. For example, the mobile navigation menu should open and close using only the tab and enter keys, without requiring a mouse click or touch gesture, so a keyboard-only user is not locked out of any section of the site. We avoid keyboard traps, meaning a reader should always be able to tab forward through every control on a page and eventually reach the footer, rather than becoming stuck inside a single widget. Skip-link patterns, where present, allow a keyboard user to bypass repeated navigation and move directly to the main article content. If a specific browser's default focus styling is unusually faint, we add supplementary styling so the focus indicator remains visible against the site's off-white background.
5. Images
Editorial images use specific alternative text describing the visible subject and context. Decorative design does not carry essential meaning. If an image is unclear or its alternative text is inaccurate, contact us with the page title. For example, alternative text for a photograph accompanying a sleep article might read "man resting in a dim bedroom with curtains partially drawn," describing exactly what is visible rather than offering a vague label such as "sleep image." A purely decorative graphic, such as a background pattern that carries no informational content, is marked so that assistive technology can skip over it without interrupting the reader's attention with an unnecessary announcement. We review alternative text whenever a template or image library changes, since a rewritten alt attribute can sometimes be lost or shortened during a redesign if it is not checked carefully. A reader who finds an image whose alternative text does not match what is actually shown is helping us catch a genuine quality issue, and we treat that report as a priority fix.
6. Colour and contrast
The visual system uses charcoal text, an off-white background, sage accents, and terracotta action elements. We test for practical readability, while recognising that display settings and colour vision differ. Important information is also expressed through words and structure. For example, the terracotta accent used for primary action buttons is paired with sufficient contrast against the off-white background so the button text itself remains legible, and the button also carries a clear text label such as "Send message" rather than relying on an icon alone. We periodically check key text and background colour pairings against a 4.5:1 contrast ratio for normal body text, which is a widely used reference point for comfortable reading. A reader with colour vision differences should still be able to distinguish a visited link from an unvisited one, because the site relies on underlining and placement in addition to colour. Where a chart or table uses colour to distinguish categories, as on the homepage comparison table, labels or patterns are also included so the information is not colour-dependent alone.
7. Documents and links
We prefer HTML pages because they adapt more reliably than fixed documents. External sites may not meet the same standard and remain responsible for their own accessibility. Tell us if a linked resource prevents access to information. For example, where an article references a downloadable resource listed on resources.php, we describe its format and general content in the surrounding text so a reader can decide whether to follow the link before doing so. We avoid relying on fixed-layout document formats for primary content specifically because such formats can reflow poorly for screen magnification or screen readers compared with an ordinary HTML page. When we link to an external government or research site, we cannot control updates to that site's accessibility features, but we try to favour established institutional sources that have their own publicly stated accessibility commitments. If a reader finds that a linked external resource is effectively unusable with their assistive technology, we will consider replacing the link with an alternative source where one exists.
8. Known limitations
Some older content may need improved heading order, more precise link context, or clearer table relationships. Third-party embedded services can also behave differently across assistive technologies. We prioritise issues that prevent access to essential information. For example, some articles published before our current editorial template was adopted may use a heading order that skips a level, such as moving from an H2 directly to an H4, which we are correcting gradually as those articles are revised for other reasons. A small number of embedded third-party elements, such as an occasional video player, may not expose full keyboard control or captions in the same way our own interface does, and we flag this limitation rather than overstate our control over that component. We maintain a simple internal list of known issues ranked by how much they affect access to core content, and we address the highest-priority items first. A reader encountering one of these known limitations before it is fixed is not experiencing a surprise to us, and reporting it still helps confirm its real-world impact and priority.
9. Feedback
Send accessibility feedback through contact.php, by phone at +62 811 2783 6059, or to the Jakarta address in the footer. Describe the page, task, assistive technology if relevant, and a preferred response channel. For example, a helpful report might state "using NVDA on Windows with Firefox, the glossary page's two-column layout reads out of order," which gives our technical reviewer enough detail to reproduce the issue directly. We welcome feedback in English or Indonesian, since both are commonly used by our Jakarta-based readership, and we will respond in whichever language the report was submitted in. A report can also be sent by postal mail to the Jl. Thamrin address in the footer for a reader who prefers not to use digital contact channels. We do not require a reader to disclose a specific disability or diagnosis to have an accessibility report taken seriously; a description of the practical barrier encountered is sufficient.
10. Response timeline
We aim to acknowledge accessibility reports within 10 working days and provide a substantive response within 30 calendar days. Complex fixes may take longer, but we will explain the interim plan and any available alternative. For example, a report about a confusing form field label might be fixed within a few days, while a report about restructuring an older article's heading hierarchy could take several weeks if it requires coordinated changes across many pages. If a fix depends on a third-party service outside our direct control, such as an embedded video player's caption support, we will say so plainly rather than promise a timeline we cannot guarantee. We will offer a practical alternative where one exists, such as providing the key information from an image or table in plain text by email, while a permanent fix is in progress. A reader who has not received an acknowledgement within 10 working days is welcome to follow up by phone at +62 811 2783 6059, since that occasionally indicates a message was not received.
11. Review
This statement was reviewed on 1 October 2026 and is scheduled for another review by 30 September 2027. Accessibility checks also occur when navigation, forms, or the visual system materially change. For example, the October 2026 review involved re-checking focus order across the redesigned homepage sections introduced that month, since a new layout can sometimes shift the order in which a keyboard moves through the page even when individual controls remain unchanged. Earlier in 2026, when the site first adopted its current colour palette, we specifically re-tested text and background contrast pairings before the change went live rather than afterward. Routine reviews are supplemented by ad hoc checks whenever a reader report identifies a genuine barrier, regardless of where that falls in the annual schedule. We expect the next full review to incorporate any updates to the WCAG guidelines published between now and the 30 September 2027 target date.
- a) 1 March 2026 — initial statement published alongside the current colour palette.
- b) 1 October 2026 — current review; homepage layout and focus order re-checked.
- c) Next scheduled review — by 30 September 2027, or sooner after a material change.
12. Commitment
Kleven welcomes specific feedback from disabled readers and assistive technology users. A report is treated as useful product information, not as a complaint to dismiss. We will keep a dated record of significant improvements. For example, if a reader's report leads to a corrected heading order on a group of articles, we note the change and its approximate date internally so the same issue is not inadvertently reintroduced in a future template update. We recognise that accessibility needs vary widely among readers, and a fix that resolves one person's barrier may not address a different need, so we remain open to further feedback even after a reported issue is marked resolved. This statement does not claim full conformance with every applicable guideline at every point in time, and we would rather state that honestly than overstate our current position. Readers are encouraged to check back on this page periodically, since the dates above reflect genuine review activity rather than a static, unchanging statement.