Accessibility Statement
Reviewed 5 October 2026. Meliora aims to make its editorial resources usable for readers with different abilities, devices and connection conditions.
This statement covers the whole Meliora website, including articles, guides, the glossary, policy pages and the contact form. It describes what we do, where we know limits exist and how to tell us about a barrier. It reflects commonly used guidance such as the Web Content Accessibility Guidelines, which we use as a reference point while recognising that conformance is something we work towards and verify over time.
The statement is written for readers who use screen readers, magnification, voice control, keyboard-only navigation or other assistive tools, and also for readers on older devices or slow mobile connections in and beyond Jakarta. It applies to the pages as they are delivered at the address above and does not cover external websites that we link to. Because the requirements that apply to a website can vary by sector and over time, we use WCAG as a practical benchmark. We describe our current position honestly, and any known gaps are listed in the sections that follow.
1. Commitment
We work toward clear structure, readable contrast, keyboard access and descriptive text. Accessibility is an ongoing practice rather than a claim that every interaction is perfect.
Responsibility for accessibility sits with the editorial desk, which reviews new pages before publication and revisits older ones when templates change. Issues are tracked in a list and prioritised by how much they affect a reader’s ability to read or complete a task. Where a fix cannot be made quickly, we try to offer another way to reach the information, such as a plain-text explanation or a reply by email.
Our working commitments are as follows.
(a) Review before publication: new pages are checked for heading order, link text, image descriptions and contrast.
(b) Review after change: a change to a template or the navigation triggers a check of the pages that use it.
(c) Responding to feedback: reports from readers are logged, assigned and followed up as described in section 10.
We do not claim a specific conformance level for the whole website, because testing is partial and the site changes as articles are added.
2. Structure
Pages use headings, landmarks, lists and tables to make long content easier to navigate. Headings are intended to follow a meaningful order and links describe their destination.
A screen reader user can move between headings to scan a long guide, jump to the main content area and reach navigation and footer links through labelled regions. Data tables use header cells so that each value can be associated with its column. Link text is written to make sense out of context, so we avoid phrases such as “click here” and instead name the destination, for example the Research page or the Glossary.
Several structural choices support navigation.
(a) A single main heading on each page, followed by section headings in a logical order.
(b) Regions for the header, main content and footer, so that assistive technology can jump between them.
(c) Lists for sets of related items, so that a screen reader announces how many items there are.
Long policy pages such as this one use numbered headings so that a reader can find a topic quickly and refer to it by number when contacting the desk.
3. Images
Editorial images include descriptive alternative text. Decorative visual treatment is not intended to carry essential meaning. Where an image is absent on policy pages, the information is provided as text.
Alternative text describes what is visible, such as the setting, the activity and the equipment, so that a reader who cannot see the photograph understands what it adds. Images are not used to present data that is not also available in the text, and charts or tables are accompanied by a written summary. Policy pages like this one contain no photographs at all, so that the content is the same for every reader.
Guidelines for describing images are applied consistently.
(a) Describe what is shown, including the setting, the activity and the visible equipment, in one or two clear sentences.
(b) Do not write “image of” or repeat the caption, since screen readers already announce an image.
(c) Leave the description empty only when the image is purely decorative and adds no information.
If a description on any page seems unclear or missing, a report to the desk will lead to a review of that image and of others on the same page.
4. Keyboard use
Navigation, links, forms and cookie controls are designed to be reachable through a keyboard. Visible focus styling helps identify the current control.
The Tab key moves forward through links and controls in a logical order, Shift and Tab moves back, and Enter or Space activates buttons. The mobile menu can be opened and closed from the keyboard, and the cookie banner buttons can be reached without a pointer. Question-and-answer items that expand and collapse can be toggled from the keyboard. If you find a control that cannot be reached, please report it so that we can fix the order or the markup.
The keyboard behaviour that readers can expect is outlined below.
(a) A visible outline around the current link, button or form field.
(b) No keyboard trap, meaning that a reader who enters a menu or a banner can always leave it with the keyboard.
(c) A logical order, which follows the reading order of the page from top to bottom.
Readers who use voice control can activate links and buttons by their visible names, which is another reason link text describes the destination.
5. Contrast
The visual system uses dark text on light backgrounds and light text on dark footer or accent areas. We review contrast when changing colors, components or content.
The body text is a dark grey on an off-white background, links and buttons use a deep teal, and the footer uses light text on a dark background. When a new colour combination is introduced, we compare the pair against the commonly used minimum contrast ratios for normal and large text. Colour is not the only way that information is conveyed, so links are also distinguished by their position or by underlines and labels.
Our approach to contrast covers more than text colour.
(a) Body text, headings and form labels are tested against their backgrounds.
(b) Buttons and links keep a clear distinction from the surrounding text, including in the hover and focus states.
(c) Light text on the dark footer is checked separately from the main content area.
Readers who prefer a different colour scheme can use their browser or operating system settings, such as a high-contrast mode, and the layout is intended to remain readable when those settings are applied.
6. Motion
Meliora avoids unnecessary animation and keeps interaction effects brief. If a future feature adds motion, we will consider reduced-motion preferences and provide a usable static alternative.
Current effects are limited to short transitions such as a hover state or the opening of a menu. There are no auto-playing videos, flashing content or moving carousels that a reader cannot pause. A reader who has set their device to reduce motion should find that essential content is unaffected. If a future page does use animation, it will be possible to read the same information without it.
The principles behind our use of motion are simple.
(a) Motion should never be the only way of understanding something.
(b) Any movement that lasts longer than a brief transition should be possible to pause, stop or hide.
(c) Nothing on the site flashes more than a few times each second.
These principles apply to both the visible interface and to any media that may be added in future, such as a short video, which would be accompanied by a transcript.
7. Forms
Contact fields have labels and required fields are identified by browser validation. A successful submission message is shown after the form is completed in the browser.
Each field is paired with a visible label, and the browser indicates which required fields are incomplete and what is wrong. After a successful submission, a confirmation message appears on the page so that a reader knows the message was sent. If you prefer not to use the form, you may email [email protected] or telephone +62 813 5271 9408 during ordinary business hours. We will treat a message sent that way in the same way as a form submission.
The contact form follows several practices.
(a) Labels remain visible and are not replaced by placeholder text alone.
(b) Error messages say what is wrong and how to correct it, using words rather than colour only.
(c) The confirmation message is placed where it is easy to find and can be read by assistive technology.
We ask only for the information needed to answer, and a reader never has to enter medical details to use the form. Information supplied is handled in line with the Privacy Policy.
8. Content barriers
Some research terms, tables or long sentences may still create barriers. We welcome requests for clarification, a simpler explanation or an accessible format.
Scientific topics can use specialist vocabulary even when we try to keep language plain, and the glossary exists to help with this. Readers who find a page difficult may ask for a shorter summary, a larger-print version or a description of a table in sentences. We will try to supply the requested format within 30 days and will tell you if more time is needed. Feedback about reading level is as welcome as feedback about technical problems.
Requests for alternative formats can take several forms.
(a) A plain-language summary of a long article, written by the desk.
(b) A text description of a table or chart, including the main figures.
(c) A copy of the page text in a format that suits your device, such as plain text, provided in a reasonable time.
We may ask which page and which format you need but we do not ask why. Requests are treated in confidence and are not used for any other purpose.
9. Compatibility
We test common modern browsers and responsive screen sizes, but assistive technology support can vary. Browser and operating system updates may change how a page behaves.
Pages are checked on current versions of widely used desktop and mobile browsers and at a range of window sizes, from small phones to wide monitors. Combinations of browser and screen reader can behave differently, and we cannot test every pairing. If you rely on a specific tool and a page does not work as expected, tell us the tool and its version so that we can reproduce the problem. Text can be enlarged through browser zoom without loss of content.
Compatibility checks include the following.
(a) Recent versions of widely used desktop and mobile browsers.
(b) Common window widths, from narrow phone screens to large monitors, including when text is enlarged.
(c) Basic reading on slower connections, because pages rely mainly on text and a small number of images.
Known limitations are recorded on the issue list with the date they were found. If a limitation affects the main content of a page, we aim to supply the information in another form while the fix is prepared.
10. Reporting an issue
Email [email protected] with the page address, the barrier and the technology used if you are comfortable sharing it. We aim to acknowledge reports within 10 business days.
After acknowledgement, we investigate and aim to provide either a fix or a plan with an expected date within 30 days. If a problem cannot be resolved quickly, we will offer an alternative way to access the information in the meantime. Reports are logged with the date received and the date resolved, and the log is reviewed at each scheduled review of this statement. You are welcome to contact us again if the issue is not resolved to your satisfaction.
A helpful report includes the following.
(a) The address of the page and a short description of what happened.
(b) The browser, device and assistive technology you were using, if you are happy to share them.
(c) How you would prefer to be contacted about the outcome, by email or by telephone.
The details you provide are used only to investigate and reply, and are kept for up to 24 months with the log entry. You do not need to give a reason for needing access, and you will not be asked for medical information.
11. Review schedule
This statement was reviewed on 5 October 2026. We review it at least annually and after significant design or platform changes.
Change log for this statement:
(a) 5 October 2026: added fuller descriptions of structure, images, keyboard use, contrast, motion, forms and compatibility, and added target response times for accessibility reports.
(b) Earlier 2026 edition: first publication of the accessibility statement for the Meliora editorial website.
Each review checks a sample of pages, covering a policy page, an article, the contact form and the navigation. The results are compared with the previous review so that new issues can be spotted. Where a review finds a problem, the fix and its date are noted in the issue list and, if the change is significant for readers, in the change log above. The next scheduled review falls within twelve months of 5 October 2026, and an earlier review will be carried out if the design or platform changes substantially.
12. Contact
Write to the editorial desk at 28 Jalan Raya Kemang, South Jakarta 12730, DKI Jakarta, Indonesia, or call +62 813 5271 9408.
The telephone line is answered during ordinary Jakarta business hours, Monday to Friday, and email at [email protected] can be sent at any time. If you contact us about accessibility, please mention the word “Accessibility” in the subject line or at the start of your letter so that it is routed to the right person.
Messages about accessibility are acknowledged within 10 business days. If you are not satisfied with the reply, you may ask for the matter to be reviewed again by another member of the editorial team, and you are free to raise a concern with any relevant Indonesian authority. Letters are accepted at the postal address above, and we will reply by the route you prefer where this is practical.