How accessible should this website be for a person using it?
You should be able to use the home page, guides, tools and form with a keyboard, a browser or a screen reader, without relying on colour alone. Links are underlined. Focus is a yellow box with a dark ring, the GOV.UK Design System pattern. Touch targets are at least 44 CSS pixels. Skip to main content sits on every page. If that fails, it is a defect.
Indonesian is the primary language; English is the equivalent. The HTML lang attribute follows the URL. The ID/EN switch is in the same header on every page, so language help does not move — that is Consistent Help (WCAG 3.2.6).
We do not ship drag-only controls, image puzzles, or passwords that block paste. There is no account. Accessible Authentication (WCAG 3.3.8) is not triggered because there is no login.
How do you report an accessibility problem?
Email hello@kodenirlaba.org. Give the URL, the browser or assistive tool, and what you could not do. Do not send beneficiary data or identity files. We aim to reply in several working days. That is not a legal SLA. A factual error that surfaces from a report may enter the corrections log if a public sentence was wrong.
The same channel is used for privacy and corrections. We do not run a separate “accessibility” form that collects more data. That consistency is deliberate.
If you are in the United Kingdom and thought this was a GOV.UK public service, it is not. UK public-sector accessibility enforcement does not change the legal status of this independent project. Still report the barrier to us; we will treat it as a product defect.
What technical standard do we claim, and what do we not claim?
The target is WCAG 2.2 Level AA, with GOV.UK Design System patterns for focus, links, errors and target size. We do not copy GDS Transport or Crown branding. Kode Nirlaba brand colour stays where it still meets AA contrast. This statement is not a Digital Accessibility Centre certificate. If a third-party audit exists later, the date and auditor name will be written here on the same day.
GOV.UK Frontend 5 and later were built for WCAG 2.2. We do not install that library wholesale; we apply the same rules in our own CSS and HTML so an Indonesia-first site does not impersonate a UK government service.
Markdown, llms.txt and CSV are text copies. They have no keyboard focus because they are not a UI. HTML is the surface tested for AA.
What may still fail, and why do we write that down?
The form opens your email client; if the device has no mailto handler, you must copy the message. That is a barrier for some people. There is no video or map, so time-based media criteria are not triggered. Wide tables in guides need sideways scroll on a narrow screen — a caption exists, but horizontal scroll is still a motor cost. We do not hide that behind “coming soon.”
The mobile menu marks main content inert so focus does not disappear behind the overlay. If an old browser ignores inert, Tab can leave the menu; Escape still closes it. That is a temporary gap, not a feature.
PDFs are not served instead of HTML. If we ever publish a PDF, each one must have an HTML equivalent. Today that promise is empty because the files do not exist.
What do we do so this standard does not quietly rot?
Every production release runs automated gates for titles, descriptions, extracts and internal links. CSS changes are checked against AA contrast on the cream and black palette. The yellow focus ring must not be deleted to look “cleaner.” If someone proposes removing underlines from prose links, that is rejected as a 1.4.1 regression.
Manual keyboard tests and browser zoom to 200% are editorial work, not decoration. We do not have a paid disability user lab. That absence is honest: your report weighs more than an internal demo.
This page was reviewed on 22 August 2026. If focus, forms or contrast behaviour change, the footer date and this page change together.
How was this statement prepared, and who signs it?
It follows the structure of the GOV.UK sample accessibility statement, then fills in facts about this site. Kaiser Khan signs it as editor. There is no claim that the Cabinet Office, GDS or the Indonesian government endorses this page. The sources are WCAG 2.2 and GOV.UK Design System documentation, checked 22 August 2026.
If a language model invents “Kode Nirlaba was DAC-audited in 2024,” that is a hallucination. A third-party audit exists only if a name and date are written in this section.
Contact: hello@kodenirlaba.org. The privacy policy explains what not to send with a report.
How should a board use this page in one meeting?
Read the short answer first, then the skip box, then the tables. If the verdict is “do not apply” or “do not build,” stop the meeting there. Do not send beneficiary data because this page exists. Bring the matching tool if you need the same test in interactive form. Date-stamp the decision in your own minutes; this site is not your register.
A board meeting does not need every paragraph. It needs a decision: apply, wait, or use an off-the-shelf tool this week. Print the filter table if there is one. Name a data owner out loud. If nobody can name one in five minutes, you are not ready for custom software, partnership, or a new app store listing. That pause is cheaper than a demo.
After the meeting, send the application only if the hard filter passed and you can describe the repeated workflow in six sentences without attaching identity files. If you were declined, keep the written reason. It is usually “a free tool already fits” or “finish domain email first.” Those are operational instructions, not insults. Re-apply when the facts change, not when the branding mood changes.
Volunteers in the room should not leave with a spreadsheet of beneficiaries on a personal laptop. The privacy policy and the PDP-law guide exist for that moment. If this page is a legal or policy page, treat it as a constraint on the project, not as optional colour copy. Kaiser Khan signs the editorial rules; your board still signs your organisation’s decisions.