Section 508 Compliance for Medicare ANOC and EOC Documents: What Carriers Need to Know

Every Medicare Advantage carrier produces the same two documents every year: the Annual Notice of Change (ANOC) and the Evidence of Coverage (EOC). Both are mailed to members ahead of the Annual Enrollment Period, both are built from CMS model templates, and both are increasingly subject to federal accessibility requirements that many production teams haven't fully mapped against their own process. This is a practical guide to what those requirements actually mean.

What the ANOC and EOC are, briefly

The ANOC summarizes what's changing about a member's plan for the coming year: premiums, cost-sharing, provider networks, formulary changes. The EOC is the fuller document, laying out the complete terms of coverage, benefits, and member rights. CMS requires both, mailed by September 30 each year, ahead of the Annual Enrollment Period that runs October 15 through December 7.

Both documents are long. EOC documents commonly run past 100 pages, sometimes past 300. Both are typically distributed as PDFs, whether by mail as printed documents or electronically through member portals and email.

Why accessibility applies to these specific documents

Electronic distribution is the part that triggers accessibility obligations. A PDF made available to members through a web portal, an app, or email is digital content, and digital content produced by an entity receiving federal financial assistance in connection with a health program is subject to federal accessibility rules, most directly HHS's Section 504 and Section 1557 rulemaking. Medicare Advantage carriers, as recipients of CMS funding to administer these plans, sit squarely inside the kind of entity these rules are written for, though the exact applicability to your organization's specific structure is a legal question worth confirming with counsel rather than assuming from a general guide.

The technical standard that “accessible” maps to is PDF/UA-1, the ISO standard for accessible PDF (ISO 14289-1). Section 508 and WCAG 2.1 AA both point back to the same underlying technical requirements when the content in question is a PDF document: proper tagging, correct reading order, meaningful alternative text, correctly structured headings and tables, and a logical document structure that assistive technology can parse.

What actually needs to be true of the file

A PDF that looks correct on screen can fail every one of these checks in its underlying structure, because visual appearance and structural accessibility are almost entirely independent of each other in how PDFs are built. Specifically, an accessible ANOC or EOC needs:

Tag structure. The PDF needs a complete, correctly nested tag tree that maps the document's actual content hierarchy, not a flat, untagged stream of text and images.

Reading order. Assistive technology reads a PDF in the order its tags specify, not necessarily the order things appear visually. A two-column layout or a sidebar callout can read out of order to a screen reader even when it looks fine visually, unless the reading order is explicitly correct in the tag structure.

Headings. Section headings need to be marked as actual headings (H1 through H6, correctly nested) rather than just bold or larger text, so a screen reader user can navigate the document by heading structure rather than reading linearly from the top.

Tables. ANOC and EOC documents are dense with cost-sharing tables, benefit comparison tables, and formulary tier tables. These need header cells properly associated with data cells so a screen reader can announce which row and column a given value belongs to.

Alternative text. Any image that conveys information, rather than being purely decorative, needs a text description. Decorative images need to be marked as artifacts so they're correctly skipped rather than announced as unlabeled images.

Language and metadata. The document needs correct language metadata set, along with a title and other identifying metadata, so assistive technology renders and announces the document correctly.

Why this is harder than it looks for CCM-produced documents

ANOC and EOC documents aren't authored freehand. They're generated from CCM platforms using templates and variable plan data, merged at scale to produce dozens or hundreds of plan-specific variants from the same underlying template. That production method has a specific consequence for accessibility: a structural accessibility defect in the template doesn't produce one bad document, it produces every variant generated from that template. A single untagged table style or a broken heading hierarchy in a shared template can silently propagate across an entire carrier's document set.

This is also why spot-checking a handful of documents isn't a reliable way to confirm compliance. The variant that gets checked can be structurally fine while a different variant, built from the same template with a different combination of plan data, has a table structure or reading-order issue the checked variant didn't happen to trigger.

How to actually verify compliance

Visual review doesn't surface these issues, since they live in the file's internal structure, not its appearance. Verification requires checking the actual tag tree, reading order, and structural metadata against PDF/UA-1, typically through a combination of automated structural validation and targeted manual review of the areas automated checks are weakest at, like alt-text quality and true reading order for complex layouts.

For a carrier producing dozens of ANOC/EOC variants per cycle, checking this by hand across the full set isn't practical on any realistic production timeline. This is the specific gap RemediTag is built to close: automated PDF/UA-1 and Section 508 validation and remediation for CCM-produced documents, built to check structural accessibility across an entire document set rather than a manually sampled subset, before documents reach a member.

Where to start

If your organization hasn't run a structural accessibility check against this year's ANOC and EOC templates, that's the place to start, before the next production cycle locks content and timelines around AEP. Confirming the technical structure is sound is a check you can run now, independent of any open legal question about which specific federal deadline applies to your organization.