Accessibility statement

1. Our commitment

We aim to make Nymera’s editorial content perceivable, operable, understandable, and robust. Accessibility is part of publishing quality, not a separate feature. This statement describes our current approach as of 5 October 2026. We use WCAG 2.2 level AA as a reference point for our work, while recognising that conformance for every page and every external document cannot be asserted without ongoing testing. Our priority is that a reader can find an article, read it, and contact the desk using the device and tools they already use. This includes screen readers, magnification, voice control, switch devices, and plain keyboard navigation. We treat reports from readers as a valuable source of information about real use. Because accessibility depends on the combination of content, browser, and assistive technology, we test with more than one combination and do not rely only on automated tools. Automated checkers find a limited share of issues, so manual review is part of every template change. Readers in Indonesia use a wide range of devices, including older phones and slower connections, and we treat these as part of accessibility. Pages are intended to remain usable on limited data plans.

2. Structure

Pages use headings, landmarks, navigation labels, lists, tables, and descriptive links to support screen readers and keyboard users. Headings are intended to follow a meaningful order. We review new templates when adding a desk or resource. For example, each page has one main heading, subheadings follow a logical sequence, and navigation is presented as a list so that assistive technology can announce how many items it contains. Tables are used for data, such as comparisons, and include header cells; they are not used for layout. Link text describes the destination, for example "Read the editorial policy", and avoids phrases such as "click here". Pages declare English as their language so that screen readers can choose suitable pronunciation. New page types are checked with a keyboard and a screen reader before release. A long article begins with a short introduction that states the topic before the detailed sections, so that readers can decide how to proceed. The footer repeats the main links, and the site map lists every page for readers who prefer a flat list to menus. Abbreviations are explained when first used, and the glossary offers plain definitions of technical terms. Content is written in English, and where a term from Bahasa Indonesia is used, it is explained in the same sentence.

3. Images

Editorial images include descriptive alternative text where they convey information. Decorative treatment is kept limited so that the reading path remains clear. If an image description is inaccurate or incomplete, please tell the desk which page and image you mean. For example, a photograph of a runner on an outdoor track is described by its visible content, while a purely decorative element is given an empty description so that a screen reader can skip it. Descriptions aim to be concise, usually a sentence, and avoid starting with "image of". Where an image carries data, such as a chart, the key information is also stated in the surrounding text. We do not place essential text inside images. Alternative text is written by editors who have seen the image and is not generated automatically and left unchecked. Photographs that show people exercising are described by the activity and setting and not by assumptions about the person. Captions, where used, add context and do not repeat the description. Images are scaled for different screen widths so that they do not cause horizontal scrolling. If you rely on a screen reader and an image is not described well enough to follow the article, please let us know so that the description can be improved.

4. Keyboard use

Links, buttons, navigation, and form controls are intended to be reachable with a keyboard. Focus should remain visible while moving through a page. Browser extensions and unusual input devices can affect the experience, so reports are valuable. Typical tests include moving through the header, menu, article, and footer using the Tab and Shift+Tab keys, opening and closing the mobile menu with Enter or Space, and submitting the contact form without a pointing device. Interactive elements are native links and buttons wherever possible, which gives them expected keyboard behaviour. A clear heading structure helps readers move past repeated navigation. If you find a control that you cannot reach or operate, please tell us which page, which browser, and what keys you pressed. The mobile menu is intended to be operable with a keyboard or switch device as well as by touch. Buttons and links are sized and spaced so that they can be selected without accidental taps. Readers who use voice control can activate controls by their visible label, because visible labels and accessible names are kept consistent. Reports of keyboard traps, where focus cannot leave an element, are treated as high priority.

5. Contrast and typography

The design uses dark charcoal text on light backgrounds and white text on dark bands. Body text is set at a readable size with generous line height, and layouts respond to smaller screens. Users can also use browser zoom without losing the main content. Text colours are chosen with a target of at least a 4.5:1 contrast ratio against their backgrounds for normal text. Information is not conveyed by colour alone; links, for example, are distinguishable by more than hue. Pages are intended to remain usable when text is enlarged to 200 percent, with content reflowing rather than requiring two-direction scrolling on a typical phone. The body typeface is set at a comfortable size and line spacing, and users can override styles with their own stylesheet or reader mode if they prefer. Link text in articles is intended to be visibly different from surrounding text. Form errors, where they appear, use words in addition to colour. Headings are larger or heavier than body text so that the structure can be seen and not only announced. Readers with low vision who set a larger base font size in the browser will see the layout respond to that setting. Line length is limited so that reading does not require tracking across a wide screen.

6. Motion and interaction

Nymera avoids autoplay media and unnecessary animation. The mobile navigation is activated by a labeled button, and the cookie banner can be dismissed explicitly. If an interaction behaves unexpectedly, a static alternative should remain available through the site map. The site does not use flashing content, and any small transitions are intended to respect the reduced-motion setting of the operating system where it is available. Video is not used for essential information, and if a video is added later, it will include captions and will not start playing on its own. The mobile menu button has an accessible name so that assistive technology can announce it. Dismissing the cookie banner with either choice is possible by keyboard. Expandable panels, where used, are built from standard controls where possible so that they announce whether they are open or closed. No essential content is revealed by hover alone. If a reader enables the reduced-motion setting, non-essential transitions are expected to be minimal or absent. Time limits are not used for reading or for completing the contact form. Any change that adds new moving or timed content will be reviewed against these principles first.

7. Forms

The contact form labels its fields and marks required information. A successful submission displays a confirmation message. Do not include sensitive medical records because the form is an editorial mailbox rather than a clinical service. Each input has a visible label, required fields are marked in text as well as by symbol, and messages are written in plain language. After submission, the confirmation message appears on the page so that screen reader users can find it. If you prefer not to use the form, you may telephone the editorial desk on the published number or write to the postal address. We will respond in the format you request where it is practical, for example by email in plain text. Error messages, where they occur, state what is wrong and how to correct it in words. Fields that ask for information such as a name or email address are intended to use standard input types so that browsers and assistive technology can suggest values. Messages are handled as described in privacy.php, and the form should not be used for emergencies, for which the disclaimer lists suitable local numbers.

8. Known limitations

Some third-party documents, linked research pages, and older browser combinations may not meet the same standard. We cannot fully control external content. We prioritize high-impact issues affecting navigation, reading order, contrast, and form completion. Examples include PDF documents that were produced elsewhere, embedded content from other sites, and archived pages that were written before our current templates. Older browsers or assistive technology versions may not support all features. Where we link to a document that is not accessible, we will try to provide a summary or an alternative on request. We review known limitations twice a year and record what has been fixed. Specific examples we monitor include older documents saved as PDF, charts reproduced from research papers, and third-party pages opened from links. When a limitation affects a task such as reading a figure, we offer a text description by email on request, usually within 14 days. Browser and screen reader combinations that are not widely used may display some elements differently, and we welcome reports of what you see. Significant limitations and their resolution are noted in the review log below.

9. Feedback

Report a barrier through contact.php or call +62 878 9652 1437. Include the page address, the task you were attempting, and your preferred contact route. We aim to acknowledge accessibility reports within seven days and investigate them in a practical order. We provide an initial assessment within 14 days and aim to fix straightforward problems within 30 days. More complex matters, such as a change to a template, may take longer, and we will tell you the expected timing. You can write to Jl. Gatot Subroto Kav. 36, Jakarta Selatan, DKI Jakarta 12950, Indonesia if email is not suitable. If you are not satisfied with our response, you can ask for it to be reviewed by a second member of the editorial team. Please say whether you want a reply by telephone, by email, or in writing, and whether you use assistive technology we should know about. We will not ask you to prove a disability or to supply medical details in order to report a barrier. Reports are logged with the date received, the page, and the outcome so that repeated problems can be seen. If a fix will take longer than 30 days, we will explain the reason and offer an alternative way to obtain the information in the meantime. You may also contact the Indonesian authorities responsible for the rights of persons with disabilities under Law No. 8 of 2016.

10. Review history

This statement was published and reviewed on 5 October 2026. We will update it when the template, navigation, form behavior, or accessibility approach changes materially. A dated note will be added when a significant correction is made. Review log: 5 October 2026 - expanded descriptions of structure, images, keyboard use, contrast, forms, limitations, and the feedback procedure; 12 January 2026 - first publication of this statement. We test major template changes before they are published and perform a broader review at least once a year. The next scheduled review is October 2027, or earlier if the layout or navigation changes. This statement is not a certificate of compliance but a description of our current practice and intentions. Planned work includes a review of the contact form and the cookie banner using only a keyboard and then a screen reader, and a check of colour contrast after any change to the visual design. Changes that fix a reported barrier are credited in the review log in general terms, without naming the person who reported it. Earlier versions of this statement are kept in the editorial archive and can be provided on request. We update the date at the top of this page whenever the statement is reviewed, even if no change is required.