Accessibility Statement

1. Accessibility commitment

Robert Bonner and the Medicare: I Get It Now! website are committed to providing a
usable experience for older adults, caregivers, people with disabilities, and visitors who
use assistive technology.

The development goal is to follow recognized accessibility practices and, where reasonably
applicable to this website, target Web Content Accessibility Guidelines (WCAG) 2.2 Level AA.
Final production testing is required before launch and after major updates.

2. Readable and understandable design

The design system emphasizes:

• large, readable text and comfortable line spacing;
• strong text and background contrast;
• clear buttons and descriptive link text;
• consistent page structure and navigation;
• plain-language headings and short sections;
• visible keyboard focus indicators;
• information that is not communicated by color alone; and
• uncluttered forms with explicit required-field labels.

3. Keyboard and screen-reader support

The code foundation uses semantic headings, landmarks, lists, buttons, links, labels, table
headers where applicable, skip links, logical source order, and accessible names.
Interactive controls should remain operable by keyboard without requiring a mouse.

Navigation menus, accordions, search and filter controls, form validation, event status, and
confirmation messages must be tested with keyboard navigation and current screen readers in
the production environment.

4. Forms, instructions, and errors

Each form field should have a visible label. Required fields should be identified in text,
not by color alone. Instructions and sensitive-data warnings should appear before
submission. Error messages should identify the affected field and be announced to assistive
technology.

Educational, event, speaking, general contact, and individualized-assistance forms should
remain clearly separated so visitors understand the purpose of each submission.

5. Images, video, audio, and downloadable files

Meaningful images should include concise descriptive alternative text. Decorative images
should be ignored by assistive technology. Videos should include accurate captions and, when
needed, transcripts or audio description. Audio content should include a transcript when
practical.

Downloadable PDFs and worksheets should use tagged headings, a logical reading order, labeled
form fields when interactive, sufficient contrast, and selectable text. An accessible HTML
alternative should be provided when a PDF cannot be made sufficiently accessible.

6. Zoom, reflow, and device support

Pages are designed to adapt across desktop, tablet, and mobile screens and to support browser
zoom and text enlargement without requiring horizontal scrolling for ordinary page content.
Visitors should be able to use portrait or landscape orientation where supported by their
device.

7. Known and possible limitations

Accessibility may be affected by third-party services or content, including retailer pages,
Google Calendar or appointment embeds, social-media content, analytics or consent tools,
WordPress plugins, older PDFs, or externally hosted media. The production site should avoid
an inaccessible embed when a direct accessible link or alternate method is available.

Because website content and software change, a feature that passes one test may later require
correction. Known issues should be documented and prioritized based on visitor impact.

8. Report an accessibility problem or request an alternative

A visitor who cannot access content, complete a form, download a resource, or register for an
event may use the Contact page. Include the page or resource name,
the problem encountered, the device or assistive technology if comfortable sharing it, and
the preferred alternative format or contact method.

Do not include a Medicare number, Social Security number, detailed health information,
banking information, or credit-card information in an accessibility message.

Until a dedicated accessibility email or telephone number is approved, the Contact page is
the supported reporting route. The production website should publish an alternate contact
method after it is configured and tested.

9. Ongoing review and improvements

Accessibility should be reviewed during content publishing, plugin updates, theme changes,
form changes, event integrations, resource production, and final quality-control testing.
Reports from visitors should be logged, investigated, and addressed when reasonably
possible.

Accessibility reference: U.S. Department of Justice, Guidance on
Web Accessibility and the ADA; WCAG is used as a technical design reference. This
statement does not claim certified conformance.