Digital accessibility report: Indonesian government websites

1. Executive summary

This study audits the digital accessibility of seven Indonesian government public service websites that are among the most visited and mandatory for citizens to use, using the international WCAG 2.2 Level A and AA standards. Testing was conducted at the homepage level and, for websites with public registration/login flows (Tax, OSS, LAPOR!), also included those pages within the testing scope.

Most notable finding: not one of the seven websites tested reached Grade C or above. Three websites received Grade D, and the rest received Grade F.

Not a single website, including the one with the relatively "best" score among the seven, came close to the passing threshold (Grade C or above). Recurring findings include: navigation elements and functional buttons that are entirely inaccessible by keyboard (found on all seven websites without exception), illogical heading structures, color contrast below standard, focus indicators that are completely invisible on three websites, and form labels disconnected from their controls in code on two websites with registration flows involving citizens' legal and financial data.

This study also gave each agency the opportunity to respond to the findings before publication, and examined the use of third-party accessibility overlay widgets as part of the analysis (without counting their presence as a score-boosting factor). The Directorate General of Immigration, despite using an overlay from UserWay and scoring the highest among the seven websites, still had core services that were entirely inaccessible by keyboard, proving that overlays do not automatically fix underlying structural problems.

The findings of this study also converge with SAFEnet's 2025 research on the three websites tested by both studies (pajak.go.id, bpjs-kesehatan.go.id, and lapor.go.id), reinforcing that the failure patterns found are not a single researcher's methodological coincidence, but a real condition experienced by users with disabilities every day.

2. Background & urgency

Public services in Indonesia increasingly rely on digital channels such as websites and mobile apps, from managing population documents, passport renewal, tax payments, and BPJS (social security) registration, to processing business licenses, all of which can now be done through official public service websites. When these websites are inaccessible to users with disabilities, they experience not just inconvenience, but also lose access to the same basic rights as other citizens.

Indonesia ratified the Convention on the Rights of Persons with Disabilities (UN CRPD) in 2011, and passed Law Number 8 of 2016 on Persons with Disabilities, which explicitly mandates accessibility of public services, including digital ones. Nevertheless, according to the Accessibility Research Report on Indonesian Public Service Websites for the Blind and Low Vision, conducted and published by SAFEnet, every website tested had barriers for blind and low vision users (SAFEnet, 2025).

The scale of the affected population is also not small, though the exact figure varies depending on the definition used. Kemenko PMK (Coordinating Ministry for Human Development and Culture) recorded around 22.97 million persons with disabilities in Indonesia in 2023, or about 8.5% of the population. Meanwhile, data from BPS (Statistics Indonesia) based on the 2020 Long Form Population Census, using the Washington Group Short Set definition, recorded a national prevalence of Type 1 disability (the broadest definition) at 6.42%. Regardless of the differences in measurement methodology, the population potentially affected by inaccessible government websites still numbers in the tens of millions.

This study was designed to provide an objective, measurable picture of the extent to which Indonesia's most critical public service websites are genuinely accessible, and to serve as a basis for advocacy and concrete improvement recommendations for website administrators.

SAFEnet, in collaboration with the Disability Center at Universitas Hasanuddin, published a similar study in 2025 that tested 20 public service websites using a combination of user testing with blind and low vision participants and technical evaluation with WAVE, focusing on the WCAG 2.1 AA standard (SAFEnet, 2025).

This study complements that work in terms of criteria coverage (WCAG 2.2 A/AA, covering motor and cognitive disabilities in addition to vision), and depth of audit per Success Criterion across seven high-volume transactional websites, accompanied by an open score per website and a formal agency response mechanism. Three websites in this study, namely pajak.go.id, bpjs-kesehatan.go.id, and lapor.go.id, were also within the scope of SAFEnet's research, allowing findings on the same websites to be compared across two studies using different methodologies.

3. Methodology

3.1 Website selection criteria

Websites were selected based on five criteria:

1. mandatory to use, with no alternative channel;
2. large active user base;
3. high risk to basic rights if inaccessible;
4. representation across government functions, not limited to a single sector; and
5. high relevance to users with disabilities specifically (for example, health and employment services).

The exception to these five criteria is Portal Informasi Indonesia, which the tester considers representative of Indonesia's "face" to a global audience.

This study deliberately limited its scope to the seven websites with the broadest user base, given the tester's time and resource constraints.

3.2 Scoring rubric

Every website starts from a score of 100, deducted for each finding based on severity level:

• Critical: −3 points
• Serious: −2 points
• Medium: −1 point
• Minor: −0.5 points

This deduction scheme was chosen after testing several steeper scale alternatives (under which scores almost always fell far below zero for every website, making them less useful for comparison).

Scores are converted to a grade using the following scale:

• Grade A: 90-100 points
• Grade B: 75-89 points
• Grade C: 60-74 points
• Grade D: 40-59 points
• Grade F: 0-39 points

Severity determination is not applied uniformly across all findings, but is tailored to each Success Criterion. Each criterion has a different pattern of impact on users, so the thresholds for Critical, Serious, Medium, and Minor are determined specifically per criterion, rather than by a single blanket definition.

For example, under 1.1.1 (Non-text Content), a functional element such as an icon-based button or link with no name at all is categorized Critical, while a decorative image not marked as empty is categorized Minor. Under 1.4.3 (Contrast Minimum), contrast that falls below the AA threshold but remains above a 2:1 ratio is categorized Serious as the default condition, and only rises to Critical if the contrast ratio is so low that it is nearly unreadable. Some criteria, such as 2.3.1 (Three Flashes or Below Threshold), which concerns photosensitive seizure risk, or 3.3.4 (Error Prevention for legal and financial transactions), do not follow this tiered gradation pattern because the scope of those criteria is by definition already specific to high-risk situations.

This granular approach ensures the final score reflects the real-world impact of a violation on users, rather than simply the number of violations found. A complete severity mapping for all 55 Level A and AA Success Criteria is included in the Appendix.

3.3 Deduplication policy

The same issue can sometimes violate more than one Success Criterion at once (for example, a label not connected to its input violates both 1.3.1 and 2.5.3). To prevent a single issue from being counted multiple times and inflating the score, findings with an identical root cause are only counted once as a score deduction; their appearance under other Success Criteria is recorded as a cross-reference without an additional point deduction, unless the two occurrences genuinely represent two independent failure mechanisms.

3.4 Testing methods

A combination of three methods was used for each criterion: manual testing (keyboard navigation, code inspection), testing with a screen reader (VoiceOver), and automated testing using browser tools (WAVE, headingsMap), with the testing date and tool versions recorded in the Appendix for replication purposes.

Testing was limited to the mobile view of each website, given that the majority of website visitors in Indonesia use a mobile phone/smartphone (StatCounter, 2026).

3.5 Accessibility overlay widget check

Every website was also checked for the presence of a third-party accessibility overlay widget. The presence of an overlay is not counted as a score-boosting factor; instead, this study specifically records whether a website using an overlay still has critical findings, as an independent data point against the instant-compliance claims often marketed by overlay products.

3.6 Right-to-respond process with relevant agencies

Before publication, each relevant agency was contacted and given 14 working days to respond to the initial findings. Responses received are included in the respective Findings per Website section; agencies that did not respond by the deadline are consistently recorded as having provided "no response."

3.7 Testing limitations

This testing was limited to the homepage level and (for certain websites) the public registration/login flow, not a comprehensive audit of every page and feature of the website. Findings represent a snapshot at a specific point in time (August 7-10, 2026) and may change as websites are updated. Testing was conducted by a single CPACC-certified auditor using a combination of automated and manual testing, not user acceptance testing with actual users with disabilities.

Testing also did not cover the full accessibility of third-party widgets (such as chat and accessibility overlays), and was limited only to the entry point leading to those widgets.

4. Findings per website

Each website is presented in a consistent format for ease of comparison:

• Brief profile and URLs tested
• Score and breakdown of findings by severity level
• Summary of key findings
• Agency response

The complete list of findings is available at Google Sheets: Findings Log.

4.1 Portal Informasi Indonesia

Portal Informasi Indonesia (Indonesia Information Portal) is a source of information about Indonesia, such as the latest news, profiles of the President, Vice President, parliament, and government agencies, as well as photo and video galleries. This website is managed by Komdigi (Ministry of Communication and Digital Affairs).

The Portal Informasi Indonesia pages tested were:

• https://indonesia.go.id, as the main page. Testing focused on the Indonesian-language version. The English-language version was only partially tested, to check the accuracy of the lang="en" attribute.

4.1.1 Portal audit findings

4.1.2 Summary of portal findings

• Links within the "Infographics" and "Photo Gallery" content cannot be accessed by keyboard. Keyboard-only users and screen reader users cannot reach these links at all.
• The language switcher toggle has no label at all. The language selection control has no accessible name, so screen reader users cannot tell what this element is for.
• The IndonesiaGoID logo has extremely low contrast (2.5:1 for the white element, 1.7:1 for the red element, far below the minimum threshold of 3:1 for non-text elements), nearly unreadable for low vision users as well as users in bright sunlight.
• Social media icons in the footer have no label. Four links (Facebook, Twitter, Instagram, YouTube) contain only an icon with no aria-label, so a screen reader only announces "link" with no context whatsoever.
• No skip link to the main content was found. Keyboard users must tab through the entire navbar and menu every time they open a new page before reaching the main content.

4.1.3 Response from portal administrators

The tester contacted the portal's administrators by email on [date] August 2026.

4.2 Directorate General of Immigration

The Directorate General of Immigration (Direktorat Jenderal Imigrasi) website provides various immigration services, ranging from services for Indonesian citizens, services for foreign nationals, Golden Visa, and more. This website uses a third-party accessibility overlay provided by UserWay.

The pages tested were:

• https://imigrasi.go.id/, as the main page. Testing focused on the Indonesian-language version. The English-language version was only partially tested, to check the accuracy of the lang="en" attribute.

4.2.1 Directorate General of Immigration audit findings

4.2.2 Summary of Directorate General of Immigration findings

• Immigration services cannot be accessed by keyboard. Access to the website's core feature (passport/visa applications and related services) cannot be reached by keyboard-only users at all.
• The chat feature and official government site information cannot be accessed by keyboard. Two other functional elements are also barriers for keyboard-only users, showing a recurring pattern rather than an isolated case.
• Social media links and app download links (AppStore/GooglePlay) have no name. These functional links are entirely unidentifiable to screen reader users.
• The focus indicator is invisible on the language menu and News items. Keyboard users lose track of their position while navigating these two components.
• The overlay does not help. Although the Directorate General of Immigration website scored the highest, the tester found no evidence that the overlay in use improves or enhances this website's accessibility. This is evident from the fact that immigration services remain inaccessible by keyboard, and several elements still lack labels.

4.2.3 Response from the Directorate General of Immigration

The tester contacted the Directorate General of Immigration by email on [date] August 2026.

4.3 LAPOR! v4.0

LAPOR! is a public complaints platform for government agencies, organized by complaint category. There are currently two live versions: v4.0, which covers 10 agencies, and v3.5, for other agencies not yet on v4.0. Nevertheless, the tester chose v4.0 on the assumption that the other agencies will eventually migrate to the newer version.

The LAPOR! v4.0 pages tested were:

• https://lapor.go.id: as the "gateway" to v4.0. Testing was limited to the website-version selection popup.
• https://prod.lapor.go.id: the v4.0 main page.
• https://prod.lapor.go.id/login: the login form.
• https://prod.lapor.go.id/register: the registration form.

4.3.1 LAPOR! audit findings

4.3.2 Summary of LAPOR! findings

• Users are not told to log in before filing a report. A user can fill out the entire complaint form, only to be told upon submitting it that they must log in first.
• The Report Category menu has no name at all. The tab menu for selecting a report category consists only of radio buttons with no aria-label, so screen reader users cannot tell what the menu is for.
• Required-field status is marked only with an asterisk symbol, which is not read by screen readers. Every required field on the complaint form is marked with an asterisk (*) only visually, with no required or aria-required attribute in the code, so required status is never conveyed to screen reader users.
• The accessible name of the Upload Attachment button does not match its visible text. The visible button text reads "Upload Lampiran," but its aria-label reads "Unggah Lampiran (...)," failing to meet the requirement that the visible label be reflected in the name announced to assistive technology.

4.3.3 Response from LAPOR! administrators

The tester contacted LAPOR!'s administrators by email on [date] August 2026.

4.4 BPJS Kesehatan

The BPJS Kesehatan (Indonesia's national health insurance agency) website provides information about the agency's profile, various types of health coverage, news and other public information, as well as links to download the app available on the AppStore and Google Play.

The BPJS Kesehatan pages tested were:

• https://www.bpjs-kesehatan.go.id/#/, as the main page. Testing focused on the Indonesian-language version. The English-language version was only partially tested, to check the accuracy of the lang="en" attribute.

4.4.1 BPJS Kesehatan audit findings

4.4.2 Summary of BPJS Kesehatan findings

• Four functional controls cannot be accessed by keyboard, including the cookie settings, slider pagination, the "News" item, and the link under "Latest Information." This recurring pattern points to a systemic problem, not an isolated case in a single component.
• Many functional elements have no name at all: the logo (navbar and footer), social media icons, AppStore/GooglePlay links, the sticky Contact link, the cookie settings button, and the ISO certification link, none of which have an accessible name.
• Color contrast on a chart is extremely low (1.4:1, far below the minimum threshold), a high-risk issue since this chart likely conveys health/membership data important to users.
• The ISO certification link has a double problem: besides lacking an alt attribute, the link also goes nowhere when clicked, a combination of a dead link and a missing label on the same element.
• The English-language version of the website still uses lang="id". Screen readers will pronounce English-language content using Indonesian phonetic rules, reducing readability for users accessing the English version of this website.

4.4.3 Response from BPJS Kesehatan

The tester contacted BPJS Kesehatan by email on [date] August 2026.

4.5 BPJS Ketenagakerjaan

The BPJS Ketenagakerjaan (Indonesia's employment social security agency) website provides information on types of membership, how to claim membership benefits, as well as news and other public information.

The BPJS Ketenagakerjaan pages tested were:

• https://www.bpjsketenagakerjaan.go.id, as the main page tested.
• https://www.bpjsketenagakerjaan.go.id/en, as the alternate English-language page. Testing on this page was limited to the lang attribute.

4.5.1 BPJS Ketenagakerjaan audit findings

4.5.2 Summary of BPJS Ketenagakerjaan findings

• Not a single element on the entire page has a visible focus indicator. Unlike other websites, which usually only lose focus visibility on certain components, the problem here is site-wide. Keyboard users genuinely have no idea which element they are on while navigating.
• Text on the main slider (hero) has extremely low contrast, as low as 1.1:1, with almost no color difference at all between the text and background, far below any minimum threshold.
• Three main navigation elements cannot be accessed by keyboard: the popup banner, the "Saya Mau" ("What I Want") menu, and the main menu below the hero. This combination makes most of the site's core navigation unreachable without a mouse.
• The Balance Calculation simulation feature (JHT/JP, Indonesia's provident/pension fund calculators) has problems at multiple layers. Input errors are only reported on the first field that is incorrect, the date-of-birth format is misread by VoiceOver, and the calculation result is not announced to screen readers at all, even though this is the most important feature on the website.
• No skip link to the main content was found, forcing keyboard users to tab through the entire navigation every time they open the page.

4.5.3 Response from BPJS Ketenagakerjaan

The tester contacted BPJS Ketenagakerjaan by email on [date] August 2026.

4.6 OSS RBA

OSS RBA (Online Single Submission - Risk Based Approach) is an integrated electronic business licensing system managed by the Ministry of Investment/BKPM (Indonesia's Investment Coordinating Board), used by business owners to process various types of business licenses in Indonesia.

The OSS RBA pages tested were:

• https://oss.go.id/id, as the main page tested.
• https://oss.go.id/en, as the alternate English-language page. Testing on this page was limited to the lang attribute.
• https://ui-login.oss.go.id/login: the login form.
• https://ui-login.oss.go.id/register: the registration form.

4.6.1 OSS RBA audit findings

4.6.2 Summary of OSS RBA findings

• Labels on the login and registration forms are not connected to their fields in code. Both of this website's core forms fail at the most basic point: screen reader users cannot tell which field is which, because the label is never associated with the input via for/id.
• Six main navigation elements have no name at all: the popup banner, the banner close button, the banner pagination, the announcement close button, the Search button, and the hamburger menu. Almost every entry point into this website is unrecognizable to screen reader users.
• No focus indicator is visible on any of the login and registration input fields. Keyboard users type without knowing exactly which field they are in.
• The popup banner, announcement banner, back button, and navbar logo are all inaccessible by keyboard. This combination means keyboard-only users can barely complete the sign-in flow at all without a mouse.
• Empty-field status on login and registration is marked only with the color red, with no supporting text or icon, so color-blind or screen reader users get no signal at all about which field has a problem.

4.6.3 Response from OSS RBA administrators

The tester contacted OSS RBA's administrators by email on [date] August 2026.

4.7 Directorate General of Taxes

The Directorate General of Taxes (Direktorat Jenderal Pajak, DJP) website provides tax information, news and regulations, as well as the CoreTax portal, the core system for tax administration, registration, and filing.

The Directorate General of Taxes pages tested were:

• https://pajak.go.id/, as the main page tested.
• https://pajak.go.id/en/index-tax, as the alternate English-language page. Testing on this page was limited to the lang attribute.
• https://coretaxdjp.pajak.go.id/.../Login: the login form.
• https://coretaxdjp.pajak.go.id/.../individual-taxpayer-registration: the registration form, under the "New Individual User without an NPWP (Tax ID)" scenario. Only the first registration page was tested in this study.

4.7.1 Directorate General of Taxes audit findings

4.7.2 Summary of Directorate General of Taxes findings

• Almost every element on the main page has no visible focus indicator. The scale is site-wide, not limited to one or two components, making keyboard navigation across the entire homepage practically untrackable.
• Nine navigation and functional elements cannot be accessed by keyboard: the popup banner, logo, Search, the "Menu" item, language selection, livechat, the tax menu, the Eselon 1 (senior official) menu, and the "Pranala" (Links) menu in the footer. This is the website with the widest scope of keyboard-access failure among the seven tested.
• Required fields on the CoreTax registration form are marked only with an asterisk symbol, with no required or aria-required attribute, on a form that involves taxpayers' identity and legal data.
• Labels on the CoreTax registration and login forms are not connected to their fields in code, including one case where the for attribute on the login page targets the wrong element (for="Username", while the field's id is "userid").
• The skip link is broken on both main pages. On the homepage, a skip link exists but its focus target is obscured and the target id cannot be found (in effect, non-functional); on the CoreTax registration/login flow, there is no skip link at all.

4.7.3 Response from the Directorate General of Taxes

The tester contacted the Directorate General of Taxes by email on [date] August 2026.

5. Cross-site analysis

5.1 Cross-site findings patterns

Inaccessibility by keyboard (2.1.1) is the most dominant pattern, found as a Critical finding on all seven websites without exception. The scale varies, from one or two elements (Portal Informasi Indonesia) to as many as nine navigation elements at once (Directorate General of Taxes). This pattern is at its worst precisely on websites with core transactional functions: immigration services on the Directorate General of Immigration website, and nearly all main navigation on the Directorate General of Taxes website, are completely unreachable without a mouse.

Functional elements with no name (1.1.1) were also found on all seven websites, generally in the form of navigation icons, social media icons, and app download links (AppStore/GooglePlay), recurring across nearly every website tested.

Three websites (BPJS Ketenagakerjaan, Directorate General of Taxes, OSS RBA) have no visible focus indicator at all, whether across the entire page or specifically on login/registration form input fields. This is the most concerning pattern because it compounds the keyboard issue above: users who manage to reach an element by keyboard still have no idea where they are.

A label not connected in code to its input was found specifically on two websites with transactional registration/login flows: the CoreTax form (Directorate General of Taxes) and the OSS RBA login/registration form. Both cases occur on forms involving citizens' legal, financial, and identity data, making the impact riskier than a similar failure on ordinary informational content.

The skip link to main content failed on all seven websites, either because it was entirely absent, or (specifically for the Directorate General of Taxes) present but broken, with its focus target obscured and the target id not found.

The Directorate General of Immigration is proof that a third-party accessibility overlay widget does not automatically fix underlying problems. Despite using an overlay from UserWay and scoring the highest of the seven websites, its core service remains entirely inaccessible by keyboard, and a number of elements are still unlabeled. This is consistent with the accessibility practitioner consensus that overlays cannot substitute for structural fixes in the source code.

Ranked by number of Critical findings, from most to fewest: Directorate General of Taxes (26), OSS RBA (16), BPJS Kesehatan (15), Directorate General of Immigration (13), BPJS Ketenagakerjaan (12), LAPOR! (9), Portal Informasi Indonesia (7). There is no clear correlation between an agency's scale/budget and the accessibility quality of its website; the website with the most critical financial/legal function (Taxes) in fact performed the worst.

5.2 Relation to SAFEnet's research (2025)

Three websites in this study, namely pajak.go.id, bpjs-kesehatan.go.id, and lapor.go.id, were also tested by SAFEnet using a combination of automated testing with WAVE and user testing with blind and low vision participants. Despite the differing methodologies, a number of findings mutually reinforce one another:

5.2.1 Directorate General of Taxes

SAFEnet explicitly noted "no skip link or shortcut to the main content" in testing with a low vision participant, matching this study's finding that the skip link on the Tax homepage is broken (focus target obscured, target id not found) and entirely absent from the CoreTax flow.

SAFEnet also repeatedly noted "some buttons have no label" and "limited keyboard navigation" across multiple rounds of testing, aligning with this study's finding of nine navigation elements inaccessible by keyboard and various functional icons with no name.

Interestingly, SAFEnet also noted that "accessibility features are available" on this website in several testing rounds, likely referring to a visual accessibility widget present on the site, yet the same note is consistently followed by keyboard navigation and label failures, a pattern matching this study's finding that the overlay on the Directorate General of Immigration website is likewise ineffective.

5.2.2 BPJS Kesehatan

SAFEnet found a problem deeper than the homepage-level scope tested in this study: the independent registration/login process fails entirely because an image-based CAPTCHA is completely inaccessible to blind users, fully blocking access to the core service.

This study did not test that deeply (the audit was limited to the homepage level), but this study's findings regarding insufficient color contrast and unlabeled navigation elements/buttons at the homepage level are consistent with SAFEnet's notes that "buttons and service navigation are not responsive to screen readers" and "text does not have sufficient color contrast."

5.2.3 LAPOR!

The tester assumes SAFEnet's report tested LAPOR! v3.5, while this study tested v4.0. Even so, the findings recorded here show a recurring pattern shared across both versions.

SAFEnet repeatedly noted that "social media icons have no alternative text label," aligning with this study's findings in the same area. SAFEnet's notes on "an important homepage notification that cannot be dismissed with a screen reader" and "no Skip to Content feature" also align with the recurring theme in this study of failing dismiss/close controls and skip links.

5.2.4 Conclusion

The convergence of findings from two independent studies using different methodologies (criterion-by-criterion audit by a certified auditor versus user testing with blind and low vision users) strengthens the validity of both studies: the failure patterns found are not a single researcher's methodological coincidence, but a real condition on the ground.

6. Recommendations

The following recommendations are drawn from the failure patterns that recur most often across the seven websites, and are not a complete list of every finding (available in full in the Appendix). Recommendations are divided into three groups: quick fixes, structural fixes, and policy/organizational recommendations.

6.1 Quick wins

The following fixes are relatively simple technically, but have a large impact because they address patterns found on nearly every website tested:

• Add an aria-label or visible text to every functional icon (logo, social media icons, search button, app download links, hamburger button) that currently has no name at all.
• Reconnect the for attribute on <label> with the id on <input> across all forms, especially login and registration forms that involve legal/financial data.
• Add a visible focus indicator (outline or box-shadow on :focus-visible) to every interactive element, especially on the three websites that currently have no focus indicator anywhere at all.
• Fix or add a skip link to main content, including making sure the target id genuinely exists in the DOM (not just that a link to it exists, as in the case found on the Directorate General of Taxes website).
• Replace single-color indicators with an additional cue (icon, text, underline) for required-field status, error messages, and chart category differentiation, so they do not rely on color alone.
• Add required/aria-required="true" attributes to every required field that is currently marked only with a visible asterisk.

6.2 Structural fixes

The following fixes require more time and coordination, since they involve how components are built, not merely adding attributes:

• Re-audit all custom components (dropdowns, date pickers, carousels, comboboxes) to follow ARIA Authoring Practices Guide patterns, particularly around role, aria-expanded, and aria-controls staying consistent between the visual state and what is announced to screen readers.
• Ensure every clickable element uses a native semantic element (<a> for navigation, <button> for actions), rather than a <div>/<article> with an event handler and no role or tabindex.
• Replace visual-only CAPTCHA verification mechanisms with an accessible alternative (for example, audio-based verification, or a method with no visual challenge at all), particularly for BPJS Kesehatan, where SAFEnet found that CAPTCHA completely blocks the independent registration/login process for blind users.
• Apply live regions (aria-live/role="status") to content that changes dynamically without a shift in focus, such as calculation results, success/error notifications, and tab changes.
• Build an internal design system with accessible-by-default components, so fixes do not need to be repeated manually for every new feature, and so implementation stays consistent across teams/agencies.

6.3 Policy and organizational recommendations

• Incorporate accessibility testing into the routine QA cycle, not just a one-time audit. The LAPOR! case is a real-world example of why this matters: the same failure pattern (social media icons with no label, an important notification that cannot be dismissed by a screen reader, no skip link available) was found consistently on both v3.5 (by SAFEnet, 2025) and v4.0 (by this study). This means the migration to the new platform version happened without fixing accessibility problems already known to exist in the previous version, a sign that accessibility testing is not yet a routine part of the development cycle.
• Avoid relying on a third-party accessibility overlay widget as the primary solution. This study's findings on the Directorate General of Immigration show that an overlay does not fix underlying structural problems, even though that website displays an overlay from UserWay.
• Train internal development teams on WCAG and manual/screen reader testing, since most of the critical findings in this study (keyboard blocking, disconnected labels) would not be caught by automated testing alone.
• Follow up the agency response process with a committed remediation timeline, not merely an acknowledgment of receipt, so there is public accountability for the improvements promised.

7. Closing

Not one of the seven public service websites most frequently accessed by Indonesian citizens managed to reach Grade C or above in this study. This is a real gap between the mandate of Law Number 8 of 2016 on Persons with Disabilities and its implementation on the ground, particularly for websites concerning citizens' basic rights: identity, health, employment, business licensing, and channels for voicing complaints.

The convergence of findings with SAFEnet's 2025 research on the same three websites reinforces that this failure pattern is not a single researcher's methodological coincidence, but a real condition experienced by users with disabilities every day. The LAPOR! case, which shows the same failure pattern between versions v3.5 and v4.0, also confirms that migrating to a new platform does not automatically mean an accessibility improvement, so long as accessibility testing has not become a routine part of the development cycle.

The good news is that most of the findings in this study are technical in nature and can be fixed incrementally, rather than requiring a total overhaul. Connecting a label to its input, adding an aria-label to functional icons, and ensuring focus indicators are visible are fixes that can be done in days, not months. Larger structural fixes, such as replacing visual CAPTCHA or building an accessible-by-default design system, do take longer, but remain realistically within reach for the agencies responsible.

The tester is open to further discussion with relevant agencies regarding follow-up audits, internal team training, or remediation support. This study is also open to replication and verification by anyone; all raw data and methodology are made openly available in the Appendix.

7.1 About the tester

This study was conducted by Rifat Najmi, founder of Radikal Studio (radikal.id), a digital accessibility consulting studio based in Jakarta. Rifat holds the CPACC (Certified Professional in Accessibility Core Competencies) certification and has spent over a decade in product design leadership, most recently serving as Head of Product Design at a number of leading technology companies in Indonesia, including Gojek, IBM, Halodoc, Traveloka, and Good Doctor.

Drawing on that experience, Rifat founded Radikal Studio with the mission of "Making Accessibility Accessible," providing WCAG audit services, inclusive design consulting, and accessibility training for organizations in Indonesia. Beyond consulting services, Rifat also maintains Panduan WCAG Indonesia, an unofficial Indonesian-language translation of WCAG 2.2, as well as Aksesibel, a publicly accessible digital accessibility education platform.

This study was conducted independently, as part of Radikal Studio's commitment to advancing public accountability for the accessibility of government digital services. Agencies or other parties wishing to follow up on the findings in this study, whether for a follow-up audit, team training, or remediation support, can contact Rifat via Radikal's website.

8. Appendix

8.1 Documentation

• Google Sheets: Findings Log
• Google Sheets: Severity Mapping
• Google Drive: indonesia.go.id documentation
• Google Drive: lapor.go.id documentation
• Google Drive: imigrasi.go.id documentation
• Google Drive: bpjs-kesehatan.go.id documentation
• Google Drive: bpjsketenagakerjaan.go.id documentation
• Google Drive: oss.go.id documentation
• Google Drive: pajak.go.id documentation

8.2 Tools used

• macOS v26.5.2 + VoiceOver
• Google Chrome v151.0.7922.109
• WAVE v3.3.1.0
• headingsMap v4.10.7

9. References

• Kemenko PMK (2023). Pemerintah Penuhi Hak Penyandang Disabilitas di Indonesia [The Government Fulfills the Rights of Persons with Disabilities in Indonesia]. Retrieved 7 August 2026, from https://www.kemenkopmk.go.id/pemerintah-penuhi-hak-penyandang-disabilitas-di-indonesia
• SAFEnet (2025). Laporan Riset Aksesibiltas Situs Web Layanan Publik Indonesia untuk Disabilitas Netra [Accessibility Research Report on Indonesian Public Service Websites for the Blind and Low Vision]. Retrieved 7 August 2026, from https://safenet.or.id/laporan-riset-aksesibiltas-situs-web-layanan-publik-indonesia-untuk-disabilitas-netra/
• StatCounter (2026). Screen Resolution Stats Indonesia. Retrieved 7 August 2026, from https://gs.statcounter.com/screen-resolution-stats/all/indonesia