Accessibility statement

Conformance target

This site targets Web Content Accessibility Guidelines (WCAG) 2.2 Level AA. Where a fix on this page cites a standard, it names the specific success criterion rather than just saying "accessibility issue" — for example, 1.4.3 Contrast (Minimum), 2.4.11 Focus Not Obscured, 2.5.3 Label in Name.

The target applies to every public page on this hub: the home page (index.html), this accessibility statement, and writing under /writing/ (currently the overlay essay). Shared presentation lives in one stylesheet (style.css) so contrast tokens, focus visibility, and sticky-header offset stay consistent across those pages.

This is a one-person personal site with no continuous integration (CI) pipeline, so conformance is checked by scan plus manual review, not by an automated gate on every change. That is a real limitation, named here rather than implied away.

What has actually been tested

• 6 Aug 2026 — automated scan (hub). accessiBe accessScan against the live home page. Returned five confirmed failures across Landmarks and Interactive Content, plus several findings judged to be heuristic mismatches rather than real defects (see Contested findings below).
• 6 Aug 2026 — manual source audit (hub). Full read of index.html against WCAG 2.2: every colour pair in the stylesheet checked against its actual contrast ratio (not eyeballed), Document Object Model (DOM) landmark structure traced, list-semantics behaviour checked against known Safari/VoiceOver quirks, focus order and skip-navigation reviewed.
• 6 Aug 2026 — remediation applied (hub). Fourteen fixes shipped in one commit: a corrected colour-contrast failure, a non-text contrast failure on the secondary button and link underlines, focus obscured by the sticky header, an ARIA label overriding visible text, article regions used where a list was correct, the entire hero content sitting outside any landmark, the mobile nav being deleted instead of made responsive, four indistinguishable "Open the repo" links, and a stale, since-corrected claim on the accessibility-research card.
• 6 Aug 2026 — shared stylesheet. Inline CSS was extracted from the hub and this statement into a single style.css, then linked from every page, so a contrast or focus fix cannot land on one page and silently miss the others.
• 6 Aug 2026 — writing page added and reviewed. The essay at /writing/overlays-supply-chain.html reuses this statement's landmark pattern (skip link to #content, main id="content", sticky topbar, one h1, section headings). Manual source review checked heading order (every section starts with an h2 or h3), list semantics for the checklist (role="list" where list markers are removed in CSS), footer link purpose, decorative hr elements marked aria-hidden="true", and first-use expansion of uncommon acronyms. It has not yet been run through accessScan as a separate live URL.
• 6 Aug 2026 — follow-up hub and statement fixes. Decorative horizontal rules on the hub and this statement marked aria-hidden="true". Decorative left-arrow characters removed from "Back to…" link names so the accessible name matches the visible purpose. Hub GitHub call-to-action announces "opens in a new tab" via visually hidden text, consistent with other new-tab links on the hub (2.4.4 Link Purpose; 2.5.3 Label in Name for the visible name).
• 6 Aug 2026 — structural keyboard and screen-reader-order pass (hub). Tab order traced end to end against the rendered Document Object Model: the skip link is the first focusable element, followed by the brand link and the five section links, then content in reading order. Every in-page link target was checked and resolves. Section headings were checked against their navigation labels. :focus-visible is defined globally and additionally on the skip link. No positive tabindex values, no focusable element hidden with aria-hidden, no unlabelled interactive element, anywhere on the hub, this statement, or the writing page.
• 6 Aug 2026 — one defect found and fixed by this pass. The hub's skip link targeted #work, a section partway down the page, instead of <main> — so a keyboard or screen-reader user activating "Skip to main content" landed past the page's own h1 and the introductory paragraph, having skipped the very content the link promised. Neither the accessScan run nor the earlier source read caught it, because both check whether a skip link and a landmark exist, not where the link actually lands relative to the page's own heading. Fixed by giving <main> id="content" and pointing the skip link at it, matching the pattern already used on this statement and the writing page.
• 6 Aug 2026 — independent re-scan of the accessScan "visibly hidden" finding. WebAIM WAVE against the live hub reported 0 errors, 0 contrast errors, and 0 alerts (AIM Score 10/10). A separate axe-core run against the same URL reported 0 violations. The only visually hidden nodes on the hub are eight intentional span.visually-hidden fragments inside links (repository names and "opens in a new tab" / email-application cues). See Contested findings.
• 6 Aug 2026 — axe-core on statement and writing page. Live scans of accessibility.html and /writing/overlays-supply-chain.html: 0 violations on both. Skip links target #content / main id="content"; each page has one h1. Visually hidden nodes on the statement are the same intentional link-purpose pattern (email application + new-tab cues); the writing page has none. Incomplete colour-contrast checks on hero text against the dotted background pattern were not treated as failures — same inconclusive class axe reported on the hub.
• 6 Aug 2026 — WAVE on statement and writing page. WebAIM WAVE against both live URLs: 0 errors, 0 contrast errors, 0 alerts on each (AIM Score 10/10). Features reported include skip link, skip link target, and document language — matching the shared landmark pattern.
• 7 Aug 2026 — VoiceOver + keyboard pass (hub, Safari). Operated the live home page with VoiceOver on, keyboard only, in Safari on macOS. Six checks: (1) first Tab reaches "Skip to main content"; (2) activating the skip link lands so the page h1 ("Open source contribution infrastructure") is reached, not the later "Current work" section; (3) top-bar Tab order is skip link, brand, Work, Method, Writing, Background, Contact; (4) heading navigation finds a single h1 then the section h2s; (5) an "Open the repo" link announces the repository name and "opens in a new tab"; (6) the footer "Accessibility statement" link is reachable by Tab and announced as a link. All six passed. Chrome was tried first; Safari was used for the recorded pass after Tab/focus behaviour was clearer there.
• What this VoiceOver pass does not cover. It is a hub-only task pass in Safari + VoiceOver. It does not include NVDA, JAWS, or TalkBack, and it does not repeat the same six checks on this statement or the writing page with VoiceOver running. Those remain open.

Known issues

• Screen-reader coverage still narrow. Safari + VoiceOver on the hub is done (see Testing log). NVDA, JAWS, and TalkBack have not been run, and VoiceOver has not been re-run on this statement or the writing page. Named here so the gap stays visible.

Contested findings

Three of accessScan's findings on the hub are heuristic rather than mechanical, and I have not changed the site to satisfy them. The same section-jump <nav aria-label="Page sections"> pattern is reused on this statement and on the writing page:

• "Visibly hidden content is exposed to assistive technology." accessScan did not return a CSS selector with the original finding, and a later attempt to reopen the report required a paid trial. The hub intentionally uses span.visually-hidden for link purpose (which repository an "Open the repo" link opens, and "opens in a new tab") — text that must remain in the accessibility tree while staying off-screen. That is the correct pattern for 2.4.4 Link Purpose, not a defect. WAVE (0 errors / 0 alerts) and axe-core (0 violations) against the live hub both declined to flag it. Selector identified by enumeration, not by accessScan: span.visually-hidden (eight instances, all inside links). Filed as contested; not "fixed" by removing the accessible names.
• "Main navigation should have role navigation." The page nav is already a correctly formed, correctly labelled <nav aria-label="Page sections">. I read this finding as the scanner expecting a site-level primary nav and not recognising a section-jump nav as one. Adding a redundant role="navigation" to an element that is already a <nav> would be exactly the kind of ARIA-over-semantics change I'd flag in someone else's pull request.
• "Navigation landmark does not contain key site navigation links." On the hub, that nav contains five in-page section anchors, not links to the project repositories or the writing pieces. The finding is arguably picking up something real — an outside visitor's most likely destinations aren't in it — but the honest description of this nav is that it navigates page sections, which is what its label says. Filed here as accepted-and-contested rather than worked around silently. Brand links in the top bar still reach the hub from every page.

Report a barrier

If something on this site doesn't work for you — on the hub, this statement, or a writing page — I want to know, even if the report is imperfect. Email ecogetaway@gmail.com (opens your email application) or open an issue on the site's repository (opens in a new tab). Useful detail, if you have it: which page you were on, what you were trying to do, what happened instead, and what browser or assistive technology you were using — but the detail is optional. A report that just says "this didn't work" is still worth sending.

Language

This statement uses direct, person-centered language and follows individual preference where it's known, whether person-first or identity-first. It avoids euphemisms like "differently abled" or "people of all abilities." Uncommon acronyms are expanded on first use where that helps readers outside a specialist audience.