WCAG 2.1 Level AA accessibility requirements for patient portals

Which rule actually makes WCAG 2.1 AA binding on you?

WCAG 2.1 itself makes nothing binding. It is a W3C Recommendation, produced by the Accessibility Guidelines Working Group of the Web Accessibility Initiative, and W3C describes its own force as advisory: "W3C recommends the wide deployment of this specification as a standard for the Web." The only obligations the document states are the five conformance requirements in its section 5, and those apply to a claim of conformance rather than to the world.

The force comes from federal rules that point at it, and those rules disagree with each other. Across the whole Code of Federal Regulations 69 sections mention WCAG, spread over ten parts. Seven instruments decide whether a digital health company is reached, and the answer turns on what kind of organisation the reader runs. Both readings were taken on 2 September 2026, against the regulatory text as it stood on 31 August 2026.

US federal instruments bearing on WCAG, from ADA title II to ADA title III, with version, level, who each binds and compliance date.

Instrument	WCAG version	Level	Who it binds	Compliance date
ADA title II, 28 CFR part 35 subpart H	2.1, the 5 June 2018 publication, incorporated by reference	A and AA	State or local government, its instrumentalities, Amtrak and commuter authorities	26 April 2027 at a total population of 50,000 or more; 26 April 2028 below that, or for a special district government
Section 504, 45 CFR part 84 subpart I	2.1, the 5 June 2018 publication, incorporated by reference	A and AA	Recipients of HHS federal financial assistance, public or private	11 May 2027 at fifteen or more employees; 10 May 2028 below fifteen
Section 508, 36 CFR part 1194	2.0, the 11 December 2008 publication	A and AA, with four criteria excepted for non-web content	Federal agencies and the US Postal Service	None by population; legacy ICT not altered on or after 18 January 2018 is grandfathered
ONC certification, 45 CFR 170.204(a)	2.0, the 11 December 2008 publication	A at 170.315(e)(1)(i), AA offered as an alternative demonstration	A developer certifying a Health IT Module to 170.315(e)(1)	None specific to WCAG
Medicaid managed care, 42 CFR 438.10(a)	2.0 "and successor versions", the one hook that is not frozen	AA, named inside a definition	Each State, enrollment broker, MCO, PIHP, PAHP, PCCM and PCCM entity	None separate; 438.10 last amended 9 July 2024
ACA section 1557, 45 CFR 92.204(b)	None named	None named	Recipients of HHS federal financial assistance, on section 1557's own wider definition of that term, which expressly includes a contract of insurance and ACA premium tax credit payments. Not the HIPAA sense of "covered entity"	Effective 5 July 2024, with no delayed date for 92.204
ADA title III, 28 CFR part 36	None; no web accessibility regulation exists	None	Places of public accommodation, expressly including "professional office of a health care provider, hospital"	No regulation to comply with, which is not the same as being out of scope: DOJ's position in the guidance appendix is that "title III covers access to Web sites of public accommodations", with no standard prescribed

Two of those rows are the ones a private company argues about, and they point in opposite directions. The DOJ title II rule at 89 FR 31320 of 24 April 2024 binds a "public entity", which 28 CFR 35.104 defines as any State or local government and its instrumentalities. A vendor is reached only through the public entity's own duty over content it "provides or makes available, directly or through contractual, licensing, or other arrangements", and section 35.204 leaves the duty and the burden of proof with the public entity. Nothing in subpart H creates a duty owed by a contractor to the Department.

The HHS section 504 rule at 89 FR 40066 of 9 May 2024 is the one that reaches a private digital health company, because its trigger is money rather than government status. section 84.2(a) applies the part "to each recipient of Federal financial assistance from the Department", and "Recipient" at section 84.10 covers "any public or private agency, institution, organization, or other entity, or any person to which Federal financial assistance is extended directly or through another recipient". For an entity principally engaged in health care, "Program or activity" reaches all of its operations, so the obligation does not stop at the funded product line. HHS states in the preamble that State Medicaid programmes receive federal funds and are covered, that managed care plans paid by a State Medicaid agency are covered as well, and that the obligations "pass down to the subgrantee or subcontractor".

The remaining rows change the shape of the question rather than the deadline. section 438.10(a) defines "Readily accessible" by reference to "W3C's Web Content Accessibility Guidelines (WCAG) 2.0 AA and successor versions", which is the only one of these hooks that follows W3C forward instead of freezing on a dated text. section 92.204(b) requires websites and mobile apps to "comply with the requirements of section 504 of the Rehabilitation Act, as interpreted consistent with title II of the ADA" and names no WCAG version at all, while section 1557 reaches further than section 504 does, because its definition of federal financial assistance at 45 CFR 92.4 expressly includes "a contract of insurance", which 45 CFR 84.10 expressly excludes. ADA title III, the title that covers a private clinic, hospital or pharmacy, has no web accessibility regulation at all: the string WCAG appears once in the whole of 28 CFR part 36, inside the 2010 guidance appendix, where it is described as "Additional guidance".

What does a Level AA claim cover?

Fifty success criteria of the 5 June 2018 text, plus five conformance requirements. WCAG 2.1 is organised under 4 principles and 13 guidelines and carries 78 success criteria in that publication: 30 at Level A, 20 at Level AA and 28 at Level AAA. Conformance requirement 1 states that "For Level AA conformance, the web page satisfies all the Level A and Level AA success criteria, or a Level AA conforming alternate version is provided", so an AA claim is the 30 plus the 20. The same count run against the current 6 May 2025 publication returns identical numbers, which is why the frozen incorporation by reference costs nothing on this point.

The five conformance requirements of WCAG 2.1 are the part buyers skip, and each one changes what has to be tested:

The five WCAG 2.1 conformance requirements, 5.2.1 to 5.2.5, and what each one does to the scope of a Level AA claim.

Conformance requirement	What it does to the scope
5.2.1 Conformance Level	One level is met in full; partial credit is not a level, although W3C invites authors to report progress beyond the level achieved
5.2.2 Full pages	"Conformance (and conformance level) is for full web page(s) only, and cannot be achieved if part of a web page is excluded"
5.2.3 Complete processes	Every page in a sequence of steps conforms, or no page in that sequence conforms
5.2.4 Only Accessibility-Supported Ways of Using Technologies	Anything relied upon has to be accessibility supported, and anything that is not has to be duplicated in a way that is
5.2.5 Non-Interference	Content the claim does not rely upon still may not block access to the rest of the page

section 5.2.2, Full pages carries a note that decides how much device testing a responsive product needs: "A full page includes each variation of the page that is automatically presented by the page for various screen sizes (e.g. variations in a responsive web page). Each of these variations needs to conform (or needs to have a conforming alternate version) in order for the entire page to conform." That note is one of the two additions WCAG 2.1 made to the conformance section it inherited from WCAG 2.0.

section 5.2.5, Non-Interference pulls four criteria outside the scope boundary altogether. Whatever a claim relies upon, 1.4.2 Audio Control, 2.1.2 No Keyboard Trap, 2.3.1 Three Flashes or Below Threshold and 2.2.2 Pause, Stop, Hide "apply to all content on the page, including content that is not otherwise relied upon to meet conformance, because failure to meet them could interfere with any use of the page". A third-party scheduling widget or a video player dropped into a portal page sits inside that sentence.

Conformance attaches to pages, so the document defines nothing at the level of a whole site. A multi-page obligation arises only through complete processes, and a patient enrolment sequence or a claims appeal flow is the shape that requirement is written for. The same structural point drives the journey work described in patient portal testing.

What has to change if the product already meets WCAG 2.0 AA?

Twelve success criteria between WCAG 2.0 of 11 December 2008 and WCAG 2.1 of 5 June 2018, five of them at Level A and seven at Level AA. WCAG 2.0 carries 61 criteria, of which 25 at Level A and 13 at Level AA make an AA claim of 38, and the 5 June 2018 text takes that to 50. DOJ put the same figure in the 2024 preamble, saying public entities "will be able to become acquainted quickly with WCAG 2.1's 12 additional Level A and AA success criteria".

Seventeen criteria are new in WCAG 2.1 in total, and five of those sit at Level AAA, outside an AA claim. The split matters when a vendor quotes seventeen new requirements at a scoping meeting:

Success criteria new in WCAG 2.1, split by Level A, AA and AAA, with the count and names at each level.

Level	New in WCAG 2.1	Criteria
A	5	2.1.4 Character Key Shortcuts, 2.5.1 Pointer Gestures, 2.5.2 Pointer Cancellation, 2.5.3 Label in Name, 2.5.4 Motion Actuation
AA	7	1.3.4 Orientation, 1.3.5 Identify Input Purpose, 1.4.10 Reflow, 1.4.11 Non-Text Contrast, 1.4.12 Text Spacing, 1.4.13 Content on Hover or Focus, 4.1.3 Status Messages
AAA	5	1.3.6 Identify Purpose, 2.2.6 Timeouts, 2.3.3 Animation from Interactions, 2.5.5 Target Size, 2.5.6 Concurrent Input Mechanisms

WCAG 2.1 also added one guideline, 2.5 Input Modalities, to the twelve that WCAG 2.0 of 11 December 2008 had. The stated goal behind the additions was three user groups: "users with cognitive or learning disabilities, users with low vision, and users with disabilities on mobile devices." Five of the twelve new Level A and AA criteria are about pointer input, device motion or reflow: 2.5.1 Pointer Gestures, 2.5.2 Pointer Cancellation, 2.5.4 Motion Actuation, 1.3.4 Orientation and 1.4.10 Reflow. The delta therefore lands hardest on a phone build and on any screen a clinician uses one-handed. Healthcare mobile app testing is where that part of the work runs.

Nothing already tested has to be retested for the version change alone. W3C states that "the success criteria in WCAG 2.1 are not changed in WCAG 2.2. Later versions add new success criteria, and do not change existing success criteria." The one exception W3C names is Success Criterion 4.1.1 Parsing.

Why is Success Criterion 4.1.1 Parsing still required?

Because DOJ and HHS both froze on a text that predates its retirement. 28 CFR 35.104 and 45 CFR 84.10 carry the identical definition: "WCAG 2.1 means the Web Content Accessibility Guidelines (WCAG) 2.1, W3C Recommendation 05 June 2018, https://www.w3.org/TR/2018/REC-WCAG21-20180605/". W3C keeps dated publications immutable, stating that "the standard at a dated URL does not change", so the two rules point at a snapshot rather than at the living document.

W3C then neutralised the criterion in the 21 September 2023 republication, which added the note "This success criterion should be considered as always satisfied for any content using HTML or XML" and a second note saying that in practice it "no longer provides any benefit to people with disabilities in itself". WCAG 2.2 of 12 December 2024 removed 4.1.1 outright, and W3C warns that authors moving up "may need to continue to test and report 4.1.1". The 5 June 2018 text carries none of that.

DOJ addressed the point directly in a footnote to the 2024 final rule: "Therefore, conformance to Success Criterion 4.1.1 is still required by subpart H of this part." The same footnote gives the reason for staying on the 2018 publication, that entities "have not had sufficient time to become familiar with the 2023 version".

Which of this can testing settle, and which of it cannot?

The success criteria are testable by design. W3C writes them "as testable statements that are not technology-specific", and each of the 50 criteria in a Level AA claim against the 5 June 2018 text produces a pass or a fail on a given page. Two of the five conformance requirements produce judgements instead.

Accessibility support is the first. The glossary sets a two-part test, that "the way that the web content technology is used must be supported by users' assistive technology (AT)" and that "the web content technology must have accessibility-supported user agents that are available to users". That is a statement about the environment the portal is used in, so it gets decided and recorded rather than measured off the page. The second is the conforming alternate version, which W3C defines by four cumulative conditions covering equal information and functionality, the same human language, currency with the non-conforming content, and a reachability mechanism. Note 3 adds that "if multiple language versions are available, then conforming alternate versions are required for each language offered", and Note 4 that "one version would need to be fully conformant in order to meet conformance requirement 1".

Guidance on how to satisfy a criterion sits outside the normative document: "Guidance about satisfying the success criteria in specific technologies, as well as general information about interpreting the success criteria, is provided in separate documents." Those separate documents move between publications, which is the mutability DOJ objected to, so a test plan that leans on them is leaning on something that can change without a rulemaking.

Testing a patient portal at Level AA means driving authenticated screens, because the pages in question are the ones a patient uses to read results and message a clinician. How PHI is handled and what is signed before the first session is therefore settled before any of that work starts. The safeguards side of the same screens is covered in HIPAA testing requirements for software, and the usability work that sits beside accessibility without replacing it in IEC 62366-1 usability validation.

Which artefacts will an auditor or a customer ask for?

A conformance claim is optional in WCAG's own terms: "Conformance claims are not required. Authors can conform to WCAG 2.1 without making a claim." A customer asking for evidence usually wants one anyway, and once it exists five components are mandatory under section 5.3.1: the date of the claim; the guidelines title, version and URI; the conformance level satisfied; a concise description of the pages covered, including whether subdomains are in scope; and a list of the web content technologies relied upon. A conformance badge counts as a claim in itself, and Note 3 to that section says a logo "must be accompanied by the required components of a conformance claim listed above".

Where third-party content or an untranslated section blocks a full claim, WCAG 2.1 provides two statements of partial conformance, one for third party content in its section 5.4 and one for language in section 5.5. Neither is a conformance level, and each has to be written rather than assumed.

Under a certification programme the artefact is different again. An ONC-ACB reports to the Certified Health IT Product List "the standard(s) or lack thereof used to meet the accessibility-centered design certification criterion", so a developer who applied no standard has that fact published under section 170.523(f)(1)(xi). The rest of that evidence chain is set out in ONC certification testing requirements.

Where does WCAG 2.1 AA work go wrong?

• The scope is decided from ADA title III, which prescribes no standard for a private clinic, and the section 504 trigger at 45 CFR 84.2(a) is never checked against the company's own federal funding.
• The claim names the portal and quietly excludes the login screen or a consent overlay, against section 5.2.2, which cannot be met if part of a page is excluded.
• Only the desktop breakpoint is tested, although Note 3 to section 5.2.2 requires each automatically presented screen-size variation to conform.
• Individual pages in an enrolment or appeal sequence pass while one step fails, which under section 5.2.3 means no page in that sequence conforms.
• The suite stops at content the claim relies upon and leaves an embedded player outside it, although 1.4.2, 2.1.2, 2.3.1 and 2.2.2 apply to all content on the page under section 5.2.5.
• 4.1.1 Parsing is dropped because the tooling reports it as obsolete, while 28 CFR 35.200 and 45 CFR 84.84 still require the 5 June 2018 text.
• An accessible alternate site is offered as the main answer, although 28 CFR 35.202(a) and 45 CFR 84.86(a) allow one "only where it is not possible to make web content directly accessible due to technical or legal limitations".
• The logged-in portal is treated as exempt under 28 CFR 35.201(d), which is written against conventional electronic documents, a term 28 CFR 35.104 limits to PDF, word processor, presentation and spreadsheet files.
• A conformance badge is published with no date, no scope description and no list of technologies relied upon, so the badge is an incomplete claim under section 5.3.1.
• The ONC certificate is cited as accessibility evidence, although 45 CFR 170.204(a) adopts WCAG 2.0 of 11 December 2008 and 170.315(e)(1)(i) requires only Level A.

What do we test against WCAG 2.1 AA?

The work starts with the instrument, because the version and the level are decided by it: which federal rule reaches the product, or which contract term does, and therefore whether the target is the 5 June 2018 text at Level AA, WCAG 2.0 of 11 December 2008 at Level A, or a rolling reference under 42 CFR 438.10(a). The scope is then fixed as full pages and complete processes, the 50 criteria are exercised against each responsive variation, the four non-interference criteria are run across everything on the page including embedded third-party content, and the results table keeps a 4.1.1 row for as long as the regulation names a text that contains it. Alternate versions and accessibility support decisions are recorded with the reason behind each one, so the claim can be defended rather than restated. We produce the evidence and the claim; the obligation under section 504 or under title II stays with the organisation that operates the service.

The same criteria reach a video consultation screen and its controls, which is covered in telemedicine app testing.

Version numbers, criterion numbers, section numbers and dates on this page were read from the WCAG 2.1 Recommendation and its 5 June 2018 publication on 2 September 2026, from the eCFR text of 28 CFR parts 35 and 36, 42 CFR part 438 and 45 CFR parts 84, 92 and 170 current to 31 August 2026, and from 36 CFR part 1194 current to 24 August 2026.