Understand the WCAG 2.2 AA target

AA includes both A and AA requirements

WCAG is the Web Content Accessibility Guidelines, published by W3C. This guide uses version 2.2, Level AA as its technical target. Level AA conformance requires meeting all applicable Level A and AA success criteria, not just the items a scanner can test.

The target applies to complete pages and complete processes. A usable event page does not make its registration journey accessible if the next step cannot be completed. Third-party content and downloadable documents need attention too.

The articles translate common publishing tasks into practical steps. They do not replace the full standard, a scoped accessibility evaluation or the District’s policy decisions.

What 2.2 adds to the team’s checks

WCAG 2.2 adds six A or AA success criteria to the 2.1 requirements. These affect components as well as editorial choices:

• Focus not obscured (2.4.11, AA): author-created content must not completely hide a component when it receives keyboard focus.
• Dragging movements (2.5.7, AA): provide a single-pointer method that does not require dragging, unless an exception applies.
• Target size (2.5.8, AA): pointer targets generally need to be at least 24 by 24 CSS pixels, or meet an exception such as sufficient spacing. Inline text links have an exception. This guide recommends larger, 44-pixel controls where practical.
• Consistent help (3.2.6, A): repeated help mechanisms should appear in a consistent relative order.
• Redundant entry (3.3.7, A): do not make people enter the same information again in the same process when it can be supplied or selected, subject to the criterion’s exceptions.
• Accessible authentication (3.3.8, AA): avoid cognitive-function tests such as memorizing or transcribing information unless an allowed alternative, assistance mechanism or exception applies.

The old Parsing criterion, 4.1.1, is removed in 2.2. Invalid markup can still cause failures under other criteria. The three new AAA criteria are not part of an AA target.

Separate requirements from working preferences

WCAG sets testable outcomes. The way the team achieves them can vary. Descriptive headings and usable keyboard controls address accessibility requirements. A second-person review, monthly link check or preferred file-naming pattern is a recommended procedure that helps maintain those outcomes.

Each article lists relevant WCAG criteria where useful. The list is a cross-reference, not a complete checklist or a certification for that content type. Document accessibility also needs format-specific checks; a PDF/UA check and a WCAG evaluation do not establish identical things.

Be precise about what has been verified

Use statements such as “the listed pages were tested on this date with these methods” rather than “100% accessible.” Preserve the test scope, results, limitations and outstanding issues. Do not treat this guide, an accessibility widget or a clean automated scan as evidence that the whole website conforms.

Before publishing a conformance claim, obtain a documented evaluation covering the claimed scope and have the statement reviewed by the responsible District owner.