Policy · Reviewed 12 February 2026

Accessibility statement

1. Our aim

Plume aims to make editorial information usable by people with different abilities, devices, languages, and levels of technical access.

The site is aimed at adults who may read on a phone, a laptop, an older tablet, or a shared computer, often over a slow connection. Plume treats accessibility as part of editorial quality, in line with the principles of Law No. 8 of 2016 on Persons with Disabilities, which supports equal access to information. The working target is WCAG 2.1 Level AA, and the site has not been formally audited against it. Plume does not claim full conformance and describes remaining gaps in the section on known limits.

Accessibility is reviewed by the editorial desk together with the person who maintains the site, and it is considered whenever a page or feature is added. The aim covers people who use screen readers, magnification, voice control, or switch devices, as well as readers with temporary or situational limits, such as bright light outdoors or a phone held in one hand. Plume also tries to keep pages light, so that readers with limited data plans or older devices can open them.

(a) Vision: contrast, text size, and alternative text.
(b) Hearing: no essential information is conveyed by sound alone.
(c) Movement: large targets and operation with a keyboard.
(d) Cognition: plain language and consistent navigation.

2. Structure

We use headings, landmarks, descriptive links, readable contrast, labels, and responsive layouts to support navigation with keyboards, screen readers, and small screens.

Each page uses a single main heading followed by ordered subheadings, so that screen-reader users can move through an article by heading. A clear landmark structure is intended to help people who use a keyboard reach the main content without moving through the whole menu. Link text describes the destination, for example Read the sleep guide, instead of the words click here. On small screens the menu collapses into a button that can be opened with the keyboard, and text is intended to reflow without horizontal scrolling at ordinary zoom levels.

Pages share the same header, navigation, and footer, so a reader learns the layout once and finds it in the same place on every page. Tables, where used, have header cells, and lists are marked up as lists. The language of the page is declared as English so that a screen reader can choose a suitable voice. Indonesian terms that appear in articles are explained in the sentence around them.

(a) One main heading per page.
(b) Ordered subheadings without skipped levels.
(c) Lists and tables marked up as such.

3. Images

Editorial images include descriptive alternative text where it conveys useful information. Decorative imagery is treated differently so it does not add noise for assistive technology.

Alternative text is written to describe what a photograph shows in a sentence, for example an outdoor walking path or a kitchen table with vegetables, and it avoids opening phrases such as image of. Purely decorative graphics are marked so that screen readers can skip them. Where an image contains text, the same wording is also provided in the page body. Readers who find a missing or unhelpful description can report it using the feedback channel below.

Photographs on Plume show everyday settings, such as a walking route, a kitchen, a gym, or a quiet room, and the alternative text states what is visible without interpreting the mood. Images do not carry essential information that is not also available in the text. Large photographs are sized so that they do not require horizontal scrolling on a phone. Animation is kept to a minimum, and nothing on the site flashes.

(a) Informative images: a concise description.
(b) Decorative images: no description needed.
(c) Images that contain text: the text is repeated in the page.

4. Forms

Contact fields have visible labels and required information is communicated in the page. The form provides a confirmation message after successful submission in the browser.

Each field has a visible label placed above the input, and required fields are identified in text and not only by colour. Error messages are intended to state which field needs attention and how to correct it. After a successful submission, the page shows a confirmation message that a screen reader can announce. Readers who prefer not to use the form can write to the Jakarta address or telephone the number listed on the contact page.

The contact form does not use a time limit, so a reader can take as long as needed to write a message. Fields use standard types, so that a phone can offer a suitable keyboard and browsers can fill in details where the reader chooses. The form can be completed using only a keyboard, and the confirmation message appears on the same page after sending. A reader who finds the form difficult to use is welcome to write to the Jakarta address or call.

(a) Visible labels above each field.
(b) Required fields indicated in text.
(c) Confirmation message after successful submission.

5. Known limits

Third-party content, older documents, browser extensions, and unusual combinations of assistive technology may not behave consistently. We continue to review these areas.

Linked material from other organisations, such as PDFs from public institutions, may not be fully accessible, since Plume does not control how it is prepared. Older downloadable documents may lack tagged headings or alternative text, and Plume will provide a plain-text version on request. Some browser extensions that change fonts or colours may interact in unexpected ways with the layout. Plume reviews these limits at least twice a year.

(a) Third-party PDFs and external pages.
(b) Older documents prepared before this statement.
(c) Less common combinations of browser and assistive technology.

Plume does not yet have a complete record of tests with every screen reader and browser, and testing so far has focused on common combinations on Android, iOS, Windows, and macOS. Content added by third parties, such as an embedded map or a linked document, may not meet the same standard. Plume asks organisations whose documents it links to for an accessible version where one exists. If a barrier prevents a reader from using something important, the editorial desk can provide the information by email or telephone.

6. Keyboard use

Interactive links and controls are intended to be reachable with a keyboard. If focus order or visibility prevents a task, please report the page and device.

The intended order of focus follows the visual order, and focused elements should show a visible outline. The menu, the cookie banner buttons, form fields, and links are meant to be operable with Tab, Shift+Tab, Enter, and Space, and the banner can be answered without a pointer. If a reader becomes stuck or cannot see where the focus is, a report that names the page, the browser, and the operating system helps the team reproduce the issue. Fixes to keyboard barriers are given priority over visual changes.

Plume does not define keyboard shortcuts of its own, so the site does not conflict with those of assistive technology. The menu button on small screens is intended to be a real button that can be activated with Enter or Space. Focus is not meant to move unexpectedly when a page loads. Readers who use voice control can say the visible text of a link or button to activate it.

(a) Tab and Shift+Tab: move between links and controls.
(b) Enter: activate a link or a button.
(c) Space: activate a button, including the banner choices.

7. Text and colour

Our design uses a restrained palette with explicit contrast on light and dark sections. Readers can also use browser zoom and operating-system contrast features.

Body text is set at 18 pixels with generous line spacing, and headings use a larger serif face to separate sections. Text and background combinations are chosen to provide strong contrast, and information is not conveyed by colour alone. Readers can enlarge text up to 200 percent with browser zoom, or use reader mode, without losing content. Plume aims to respect operating-system settings such as high contrast and dark mode where the browser passes them to the page.

Link text is meant to be distinguishable from surrounding text by more than colour alone, and buttons keep their label visible in each state. Large blocks of text are broken into short paragraphs, and the line length is kept within a comfortable range. Readers who need larger text can use the browser’s zoom, and the layout is intended to adjust up to 200 percent without hiding content. Motion is limited to simple transitions.

(a) Body text: 18 pixels.
(b) Zoom: up to 200 percent.
(c) Information: not conveyed by colour only.

8. Feedback

Send accessibility feedback through contact.php or write to Jalan Melati 15, RT.002/RW.005, Cilandak Barat, Jakarta Selatan, Daerah Khusus Ibukota Jakarta 12430, Indonesia.

A useful report includes the page address, a short description of the difficulty, the device and browser used, and any assistive technology involved. Reports can be sent without giving a full name, though a contact method is needed for a reply. Messages sent through contact.php receive a confirmation on screen, and the editorial desk can also be reached by telephone on +62 812 5558 7643 during weekday business hours in Jakarta.

Feedback is read by the editorial desk, which decides whether a barrier can be resolved quickly or requires a design change. Reports can be written in English or Indonesian. Plume keeps a short record of reports, without names where they are not needed, to see which areas of the site cause the most difficulty. The telephone number is available for readers who find written contact difficult.

(a) Page address and title.
(b) What was difficult and what was expected.
(c) Browser, device, and assistive technology, if any.

9. Response

We aim to acknowledge accessibility reports within 30 days. Include a description of the barrier, page address, browser, and an alternative contact method if a reply is wanted.

Reports are acknowledged within 30 days, and urgent barriers that stop a reader from reading or contacting the desk are acknowledged within 5 working days. After acknowledgement, Plume tells the reader whether the problem can be fixed, when, and what alternative is available in the meantime, such as a plain-text version of an article. Where a fix is not possible, the reason is recorded. A reader who is not satisfied with the response may ask for a review by a different member of the editorial desk.

Alternatives offered while a barrier is being fixed include a plain-text version of an article, a summary read over the telephone, and a copy sent by email. If a document is requested in a different format, Plume aims to provide it within 10 working days. A reader who remains dissatisfied can raise the matter with the Indonesian authority responsible for the rights of persons with disabilities, and Plume will provide the details of its response for that purpose.

(a) Acknowledgement: within 30 days, or 5 working days for urgent barriers.
(b) Plan: stated in the reply.
(c) Review of the decision: by a different member of the desk, on request.

10. Review history

This statement was reviewed on 12 February 2026. Plume will update it when the site, standards, or known limitations materially change.

Log of reviews: 12 February 2026, reviewed headings, link text, form labels, keyboard operation, and colour contrast across the main sections, and expanded this statement. The statement is reviewed at least once every twelve months, and the date shown at the top of the page is updated after each review.

Reviews cover a sample of the main page types, which are the home page, an article page, the contact page, and the policy pages, and they use a checklist that includes headings, link text, labels, contrast, keyboard operation, and zoom. Findings are recorded with the date and are used to set priorities for the following period. Improvements to keyboard access and form messages come before changes of appearance.

Additional log entry: 12 February 2026, added detail on supported needs, markup practice, image descriptions, form behaviour, keyboard operation, text sizing, and alternative formats.