Why Government Websites Should Stop Auditing Against WCAG 2.0

by Gerson LacdaoOctober 19, 2026 | 4 min read
A fountain pen signing a document marked with a red AUDIT stamp.

Every government agency that has approached us about a website accessibility audit has asked the same thing. Can you validate against WCAG 2.0 as mandated by DICT?

I ask one back. Are you doing this for compliance, or to help citizens with disabilities use your site? The two are not necessarily the same, and the answer usually tells the agency which version to audit against.

DICT’s Memorandum Circular No. 004-2017 (MC 4) sets WCAG 2.0 as the legal minimum. A minimum is not a sensible audit baseline nowadays. Anyone scoping a government accessibility audit in 2026 and onward should test against WCAG 2.2 Level AA. Here are the reasons why.

2.0 was written for a web that no longer exists

WCAG 2.0 is a 2008 document. It was recommended before responsive design and touch input were even a thing, and many Filipinos now reach government services on a phone. Nothing in 2.0 asks whether a page works in both portrait and landscape, gives a tap target large enough to hit reliably, reflows at 320 pixels (typical width of mobile screens), survives a text-spacing override, or offers an alternative to a drag gesture. WCAG 2.1 and 2.2 cover all of those. An audit scoped to 2.0 cannot report a single one of them as a failure leaving a website inaccessible even after passing a 2.0 audit.

The ISO reference has already moved

MC 4 adopts WCAG 2.0 by way of ISO/IEC 40500:2012. In October 2025, ISO approved WCAG 2.2 as ISO/IEC 40500:2025. The number the circular cites now resolves to 2.2. Europe has moved the same way, with the EN 301 549 update shifting its web baseline from WCAG 2.1 to WCAG 2.2. Testing to 2.0 lags the very standard the policy points to.

2.0 still carries an obsolete criterion

The W3C removed Success Criterion 4.1.1 Parsing in WCAG 2.2, because the parsing problems it described no longer break assistive technology. An audit against 2.0 must still report unclosed tags, improperly nested elements, and duplicate attributes as failures, even though modern browsers resolve all of them identically. Agencies then spend public money and developer hours on markup cleanup that changes nothing for users.

The upgrade costs almost nothing

WCAG 2.2 is backward compatible. Meeting 2.2 means meeting 2.1 and 2.0, so a 2.2 report still answers the MC 4 question and more. The nine added criteria are mostly design decisions rather than rebuilds.

  • Do not hide the focused element behind a sticky header.
  • Do not require dragging.
  • Keep targets big enough to hit.
  • Keep the help link in the same place on every page.
  • Do not ask for the same data twice.
  • Do not gate login behind a memory test or a puzzle.

Compare that list to what government sites actually ask of people. Permit applications run to six steps. Portals send an OTP and then show a CAPTCHA. Forms make a citizen retype the same address three times. Accessible Authentication and Redundant Entry decide whether someone with a cognitive disability finishes a transaction alone.

An ask for DICT

The deeper problem is that MC 4 names a version number. Nine years later, agencies are still steered toward 2008 guidance because a document says so.

DICT should issue a new circular superseding MC 4, adopting the current W3C Recommendation of WCAG, which is 2.2 as ISO/IEC 40500:2025, and setting a transition period after each future release instead of naming one version. A circular written that way does not expire. When WCAG 3 reaches Recommendation status, whenever that happens, the Philippines will not need another circular and another nine-year wait.

Until then

Audit at 2.2 AA. Report 2.0 conformance in a separate column so agencies can see where they stand against the mandated minimum, and treat a 2.0 failure as the serious finding it is. Developers build to whatever the audit measures, so an audit that measures only 2.0 teaches a team to stop there.