Accessibility

Automatic checks on every page. Every public page and every member page was rendered: 102 pages, signed out and signed in. Each one was checked for the same things:

• the page has a language (lang) and a writing direction (dir);
• one main landmark, and a skip link to it before anything else;
• one h1, and no heading level skipped;
• a text alternative on every image;
• a name on every form field, button and link;
• unique ids, and aria-labelledby pointing at ids that exist;
• no positive tabindex;
• a title on every frame.

The same checks run in the test suite (tests/Feature/i18n_AccessibilityTest.php) on the busiest public and member pages, in English and right to left. A regression fails the build.

Colour. The packaged palette was measured. Every text and background pair the views use reaches 4.5:1 or better. The weakest pair is brass-600 on cream-200, at 5.05:1. The lowest body-text pair is ink-500 on cream-50, at 7.68:1.

Code review of the views and the site's stylesheets:

• landmarks, heading order and labels;
• focus styles (:focus-visible);
• the skip link;
• the custom widgets: the menus, account menu, search pop-up, reactions, lightbox, cookie settings and install sheet, which all use aria-expanded, aria-pressed, aria-controls and close on Escape;
• touch targets (44 px, enforced by earlier tests);
• reduced motion.

Four more checks (each one is a test, so a regression fails the build):

• Form errors. Every error message in the public and member views (about 240) has an id, and its field points at it (aria-describedby) and says it is invalid (aria-invalid). A real failed submit is checked end to end. Long forms (about 20, from joining and the profile to event registration and the shop checkout) open with an error summary: announced, focused, one link per problem (tests/Feature/i18n3_FormErrorsTest.php).
• The admin panel. Every admin screen (about 190) is rendered and given the checks above: language, one h1, heading order, alt text, labels, names, unique ids, ARIA references, no positive tabindex (tests/Feature/i18n3_AdminAccessibilityTest.php). Filament's own components that fail a static check are listed below.
• Keyboard. Every view and stylesheet is scanned: nothing reacts to a click without being reachable by Tab, no positive tabindex, every pop-up that announces open/closed (aria-expanded) closes with Escape, and a focus ring is never removed without a visible replacement (tests/Feature/i18n3_KeyboardTest.php).
• Touch targets of the admin's own controls, the footer widgets, the cookie banner and short labels: 44 x 44 px on touch screens, by growing the area that takes the tap, never the control (tests/Feature/i18n3_TouchTargetsTest.php).

Names and roles, checked by the supplier on the main journeys (release 2.0.0). Sign in, join, donate, event registration, the directory, the profile, and an admin list and edit screen (members and events) were rendered, signed out and signed in, and every control was checked for its name and its role (WCAG 4.1.2): links, buttons, fields and anything with an ARIA widget role have a name; every role is a real ARIA role and carries its required state (aria-checked on a switch, aria-expanded on a combobox); state values are valid; nothing clickable lacks a control role or keyboard access; radio buttons and check boxes that share a name are a named group; nothing focusable is hidden with aria-hidden; dialogs and repeated navigation landmarks are named. 20 pages, 2,109 elements. It found that the header's two menus (wide and narrow screens) were unnamed navigation landmarks; they are now named "Main menu". The only remaining failures are in Filament's own components (Known gaps, item 8) (tests/Feature/trust_NamesAndRolesTest.php).

Not done yet. Names and roles were checked by the supplier; no screen-reader testing has been done. There was no test with screen readers (NVDA, JAWS, VoiceOver, TalkBack), no keyboard-only walk through every flow in a real browser, and no test with users with disabilities. The keyboard checks above read the code; they do not press keys. Those are the next step, and they are what a formal audit would add.

1. Form errors on short forms. Every field points at its own error, but only the long forms have the announced summary. On a one- or two-field form a screen reader user hears the error when they reach the field.
2. Timing.
   • A ticket reservation is held for a set time (Settings > Events, jobs & volunteering), with the time shown on the page.
   • The admin session ends after 60 idle minutes with no warning.
   • The giving-day clock updates every second and cannot be paused.
3. Sticky header and focus. On small screens the sticky header can partly cover a focused element near the top of the window (WCAG 2.4.11).
4. Content added by your team. Alt text for uploaded photos, captions for embedded videos, link wording in news posts and the accessibility of attached documents all depend on what is entered. Every image field has an alt-text box; fill it in.
5. Colours you choose. Settings > Theme & colours lets you change the site colours. A choice with poor contrast is not blocked.
6. Documents we generate (PDF receipts, invoices, the membership card) are not tagged PDFs.
7. The member map is a pointer-oriented map. The same members are listed on the directory page, which is fully keyboard and screen reader friendly.
8. The admin panel relies on Filament for keyboard and screen reader support. Reordering by drag and drop has up and down buttons on most screens, but not on all of them. The automatic checks find these in Filament's own components (not AlumDeck's), on the screens that use them:
   • the rich text editor's panel close button (Blocks, Merge tags) has no name;
   • the markdown editor's source box has no label of its own (the editor shows the field's label);
   • the search boxes, a multi-select tag's remove button and the date picker's button get their names only when Filament's script runs; a static check cannot confirm them;
   • the menu group headings, collapsible section headings and the backdrop of the mobile menu react to a click without being controls; each has its own named button that does the same by keyboard.

Based on VPAT 2.5 Rev (WCAG edition).

• Product: AlumDeck 2.0.0. Public site and member area; the admin panel is noted separately.
• Report date: 3 October 2026 (first draft 26 September 2026).
• Evaluation methods:
  • automatic checks of the rendered HTML of 102 public and member pages and about 190 admin screens;
  • a rendered failed form submit, and a scan of every error message and its field;
  • a scan of every view and stylesheet for keyboard access and focus visibility;
  • a colour contrast calculation for the packaged palette;
  • a code review of the views, stylesheets and scripts;
  • names and roles checked by the supplier on the main journeys (sign in, join, donate, event registration, directory, profile, an admin list and edit screen).
• Not used: assistive technology testing and user testing. No screen-reader testing has been done.
• Draft status: this is a supplier's draft, not an independent audit. The terms follow the VPAT definitions:
  • Supports;
  • Partially Supports (some functionality does not meet the criterion);
  • Does Not Support;
  • Not Applicable.

Table 1: WCAG 2.2 Level A

Table 2: WCAG 2.2 Level AA

Admin panel

The admin panel uses Filament 5. Its forms, tables, modals and notifications follow Filament's own accessibility support. AlumDeck's screens add their own labels (translated) and use Filament components; the custom parts are the dashboard widgets, the Getting started checklist and product tours, the Help pages, the import and report pages and the admin themes.

Every admin screen (about 190) passes the automatic checks listed under "What was checked": AlumDeck's own markup has no failures. The remaining static failures are in Filament's own components (Known gaps, item 8). No screen reader or keyboard walk-through of the panel has been done, so this report makes no conformance claim for the admin panel beyond those checks.