Plymouth · 1620 Maryland · 1938
Society of Mayflower Descendants — Maryland

At a glance

Audited, then remediated.

Update — July 13, 2026: all 14 findings below (4 serious, 5 moderate, 5 minor) have been remediated in the site’s code. Each item is marked Resolved with the fix that was applied. A final pass with a live screen reader is still recommended before publishing a formal accessibility statement.

The site rested on a strong accessible foundation — a working “skip to content” link, a declared page language, semantic landmarks and headings, keyboard-operable navigation, image alternative text, and labelled form fields. No barriers were found that made any page impossible to use with a keyboard or screen reader.

The audit identified 4 serious, 5 moderate, and 5 minor issues — chiefly around form validation messaging, a few dynamically-added form fields, and one data table built without table markup. All have since been fixed.

How this was assessed

Scope & method.

Standards
WCAG 2.1 Level AA; Section 508 (2017 Refresh)
Date of audit
July 13, 2026
Method
Manual source review & colour-contrast analysis
Scope
Public-facing pages & forms
Status
All 14 findings remediated — pending screen-reader verification
Re-test
Recommended with a live screen reader (VoiceOver / NVDA)

Every public page was reviewed: the home page; the About, Pilgrims, Membership, Contribute, and Events sections; and all public forms (Contact, Pay Dues, Donate, Membership Application, Event Registration, and Scholarship Application). Colour combinations from the site’s palette were measured against the WCAG contrast formula.

Note on scope. This is an expert manual and code-level review. It is the right first step, but it does not replace testing with real assistive technology (screen readers such as VoiceOver, NVDA, or JAWS) and people who rely on it. Member-only and administrative pages were out of scope for this public report.

The two standards

WCAG and Section 508, aligned.

Since its 2017 “Refresh,” Section 508 of the Rehabilitation Act adopts WCAG Level A and AA success criteria by reference for web content (508 chapters E205 and the 301–702 requirements). In practice this means: meeting WCAG 2.1 AA satisfies the web-content requirements of Section 508. The findings below therefore carry both a WCAG success-criterion reference and the corresponding 508 provision.

By principle

Conformance summary.

WCAG 2.1 AA status by POUR principle (after remediation)
Principle Status Notes
Perceivable Meets The fee schedule is now a real data table; decorative glyphs are hidden from assistive tech; the focus ring and muted-text contrast were raised to pass. Alt text and headings were already sound.
Operable Meets Full keyboard access, working skip link, focus is managed in the mobile menu, dropdowns open on keyboard focus, and reduced-motion preferences are now honoured.
Understandable Meets Form errors are now tied to their fields and announced; status messages use live regions; personal-detail inputs carry autocomplete hints.
Robust Meets Valid, semantic markup. Script-added fields now carry accessible labels, and status regions announce updates.

What was found & fixed

Findings & remediation.

Severity reflects how much each barrier affected people who rely on assistive technology. Every item is now marked Resolved, with the fix that was applied.

Serious Moderate Minor Resolved

Serious

A-01 Form errors aren’t announced to screen readers Serious Resolved

When a form is submitted with mistakes, the error text appears next to each field visually, but it is not programmatically tied to the field (no aria-describedby / aria-invalid) and isn’t placed in a live region. A blind user hears nothing change and may not know what went wrong. Affects every public form.

WCAG
3.3.1 Error Identification (A) · 1.3.1 Info & Relationships (A) · 4.1.3 Status Messages (AA)
Section 508
E205.4 (incorporates WCAG A/AA)
Fix applied
Link each error message to its field with aria-describedby, set aria-invalid="true" on invalid fields, and move keyboard focus to a role="alert" error summary on failed submit.

A-02 Script-added fields labelled only by placeholder Serious Resolved

The “add another member” rows on Pay Dues and the extra-attendee / meal-choice rows on Event Registration are created by JavaScript and carry only a placeholder (e.g. “First name”) for their name. Placeholders are not a substitute for a label — they vanish on typing and some screen readers ignore them.

WCAG
1.3.1 Info & Relationships (A) · 3.3.2 Labels or Instructions (A) · 4.1.2 Name, Role, Value (A)
Section 508
E205.4
Fix applied
Add an aria-label (or a visually-hidden <label>) to each dynamically-generated input and select.

A-03 Missing “autocomplete” on personal-detail fields Serious Resolved

Name, address, e-mail, and phone fields across the application, scholarship, donation, dues, and contact forms have no autocomplete attribute. These hints let browsers and assistive tools fill known information — a meaningful help for people with motor or cognitive disabilities. The two long application forms are the largest gap.

WCAG
1.3.5 Identify Input Purpose (AA)
Section 508
E205.4
Fix applied
Add the standard tokens — given-name, family-name, address-line1, address-level2, address-level1, postal-code, tel, email.

A-04 Fee schedule built without table markup Serious Resolved

On the Membership › Fees page, the dues schedule is laid out with styled <div> blocks rather than a real <table>. Screen-reader users lose the row/column relationships and can’t navigate it as a table or hear which amount belongs to which item.

WCAG
1.3.1 Info & Relationships (A)
Section 508
E205.4
Fix applied
Rebuild as a <table> with a <caption> and <th scope> headers (the table on this report page is a working example).

Moderate

A-05 Success / status messages aren’t announced Moderate Resolved

Flash confirmations (“Your message was sent”) and the live registration total are rendered without role="status" / aria-live, so screen-reader users aren’t told the outcome or the updated price.

WCAG
4.1.3 Status Messages (AA)
Section 508
E205.4
Fix applied
Wrap flash messages in role="status" and the running total in an aria-live="polite" region.

A-06 Low-contrast focus outline on application forms Moderate Resolved

Application and scholarship form fields show a gold focus outline (#eaab01) on the cream background. Measured contrast is 1.73:1, below the 3:1 a focus indicator needs — keyboard users may not see where they are. (Most other fields use a crimson ring, which passes.)

WCAG
1.4.11 Non-text Contrast (AA) · 2.4.7 Focus Visible (AA)
Section 508
E205.4
Fix applied
Switch the focus ring to crimson (#9b2639, 6.5:1) or a darker gold, site-wide.

A-07 Heading levels skip on the home page Moderate Resolved

The home page jumps from <h2> to <h4> in the timeline section and has a stray <h3> with no parent <h2> in the dues strip. Screen-reader users navigating by heading hear a broken outline.

WCAG
1.3.1 Info & Relationships (A) · 2.4.6 Headings & Labels (AA)
Section 508
E205.4
Fix applied
Use sequential levels (h2 → h3) without skipping.

A-08 Double-escaped &amp; in a button label Moderate Resolved

The Event Registration button renders the literal text Register &amp; pay, which a screen reader reads as “Register ampersand amp semicolon pay.”

WCAG
4.1.2 Name, Role, Value (A) · 1.3.1 (A)
Section 508
E205.4
Fix applied
Output a plain ampersand (don’t pre-escape inside {{ }}).

A-09 No “reduced motion” support; content hidden until script runs Moderate Resolved

Most sections fade and slide in on scroll. They start fully transparent and are only revealed by JavaScript, and there is no prefers-reduced-motion handling for visitors who ask their system to minimise animation (often because motion triggers nausea or migraine).

WCAG
2.3.3 Animation from Interactions (AAA, advisory) · robustness if scripting fails
Section 508
Best practice
Fix applied
Honour @media(prefers-reduced-motion: reduce) by showing content with no transition, and ensure the reveal class defaults to visible.

Minor

A-10 Decorative icons & glyphs not hidden from assistive tech Minor Resolved

The inline arrow <svg> in call-to-action buttons, and the decorative “→” and “·” characters in lists and rows, lack aria-hidden="true" (the header/menu icons already do this correctly).

WCAG
1.1.1 Non-text Content (A)
Section 508
E205.4
Fix applied
Add aria-hidden="true" to purely decorative icons and glyphs.

A-11 Muted text on darker cream is borderline Minor Resolved

Muted brown text (#6a6151) on the deepest cream panel (#e3d2ad) measures 4.09:1, just under the 4.5:1 required for normal-size text. On the standard background it passes comfortably (5.19:1).

WCAG
1.4.3 Contrast (Minimum) (AA)
Section 508
E205.4
Fix applied
Darken muted text one step, or reserve it for large text on the deep panels.

A-12 Gold used as small text fails contrast Minor Resolved

The gold accent (#eaab01, 1.73:1 on cream) and deep gold (#b88600, 2.77:1) appear as small label / year text in a few decorative spots. Fine as accents, but they shouldn’t carry essential small text.

WCAG
1.4.3 Contrast (Minimum) (AA)
Section 508
E205.4
Fix applied
Keep gold for large/decorative type only; use ink or crimson for informative small text.

A-13 A few generic link phrases Minor Resolved

A handful of links read “contact page” or “here.” The surrounding sentence gives context, so this is low-impact, but more descriptive link text helps people who navigate by a list of links.

WCAG
2.4.4 Link Purpose (In Context) (A)
Section 508
E205.4
Fix applied
Prefer self-describing link text, e.g. “visit our contact page.”

A-14 External links don’t signal a new tab Minor Resolved

Research links open in a new tab (correctly using rel="noopener") but don’t warn the user first. This is an advisory (AAA) item, not a failure.

WCAG
3.2.5 Change on Request (AAA, advisory)
Section 508
Best practice
Fix applied
Add a visually-hidden “(opens in a new tab)” note.

Credit where due

What the site does well.

  • Skip link & landmarks. A working “Skip to main content” link, plus <header>, <nav>, <main>, and <footer> regions with ARIA labels.
  • Keyboard operable. Drop-down menus open on keyboard focus, the mobile menu traps and restores focus, and Escape closes it.
  • Language & titles. Every page declares lang="en" and a unique, descriptive <title>.
  • One H1, logical headings. A shared page component enforces a single <h1> with sensible, sequential sub-headings on every page.
  • Image alternatives. The crest and logos carry meaningful alt text; no image is left undescribed.
  • Labelled, grouped forms. Fields use real labels, related controls sit in <fieldset>/<legend> groups, and required fields use the native required attribute.
  • Strong text contrast. Body text runs 10:1–15:1 against the page; links and crimson headings clear AA comfortably.
  • No colour-only meaning. Vacancies, emphasis, and states all carry a text label as well as colour.
  • Safe external links. Off-site links include rel="noopener" and descriptive text.

Prepared as an internal conformance review for the Board of the Society of Mayflower Descendants in the State of Maryland. It reflects the state of the public site on July 13, 2026, after all fourteen findings were remediated in code. The recommended next step is a confirmation pass with a live screen reader (VoiceOver, NVDA, or JAWS) and a keyboard-only run-through before publishing a formal accessibility statement.