Evidence / Accessibility checklist and learning reference
The A11Y Project
A practical starting point for turning accessibility intent into review tasks people can actually perform.
Understand the resource
What it is.
The A11Y Project is a community-maintained collection of accessibility explanations, resources and a manual review checklist. It helps a team notice common content, keyboard, form and media problems before those problems become a release surprise. Its checklist is a prompt for investigation; it does not inspect your application for you.
When it is useful
Use it when a designer, content author and developer need a shared review agenda. It is especially useful for a small team that has automated checks but no consistent way to record manual findings and ownership.
A proposed application
Put it to work.
This example illustrates a possible use. The proposed workflow and expected result are separate from the bounded checks recorded below.
Try this
For a new service-request form, assign the content items to an editor and the keyboard and form items to a developer. Test a synthetic request from first field to confirmation, then record the page, observed failure, expected behavior and fix owner for each relevant item.
Result to aim for
A scoped accessibility issue list with reproducible evidence and owners, plus an explicit list of items that still need specialist or user testing.
Before you start
What you need.
- A browser for the reference and access to the product you are reviewing.
- Someone who can perform manual keyboard and content checks, with assistive-technology expertise for the checks that require it.
- A separate issue tracker or review log; clicking a website checkbox is not a durable team audit record.
The practical boundaries
What to watch for.
- The checklist says it is not comprehensive. Completing its boxes is not a WCAG conformance decision or proof that disabled users can complete your workflow.
- Check the version of each linked criterion. The reviewed checklist still links to 4.1.1 Parsing, which W3C marks obsolete and removed in WCAG 2.2; useful HTML hygiene and current conformance criteria are different things.
- A checklist item can cover several contexts. Test errors, dialogs, zoom and keyboard states in the actual product instead of accepting one screenshot as evidence.
Review record
What we could establish.
- Why included — 2026-10-19: the official community repository had 3,902 stars and 619 forks in the unauthenticated GitHub API snapshot. That supports established community interest; a single snapshot does not establish recent trend growth.
- The checklist and current W3C parsing note were reviewed. One checkbox was exercised with the keyboard; the 64 checklist controls were counted, not individually tested.
The source-review notes describe documentation and identity. The account-free evaluation below records exactly which public interaction or local fixture was checked, what happened, and what remains untested.
Check current access, terms, licensing and data handling before using a resource with your own material.
Runtime and security evaluation
What the evaluation covers.
The public checklist loaded and one item toggled on and off with Space. This checks the reference page’s control, not the accessibility of any application or the completeness of the checklist.
Methods: Public HTTP response · Public browser sample · Source review. A completed check covers the stated sample; it is not a safety certification.
- Target
- https://www.a11yproject.com/checklist/
- Version or capture
- Unversioned public hosted page sampled on 2026-10-19; no installed package version attested.
- Integrity scope
- Recorded document SHA-256 0ef7aed28e1c7969902251e87a4fe3c2cc5659524ac70abed2507563e3890996. This is the HTML response only, not an integrity guarantee for scripts, dependencies or the whole service.
Test conditions
- Fresh anonymous Chromium 155.0.8059.82 context on Windows; 1365 × 900 viewport; reduced motion requested.
- GET and HEAD only; non-GET methods and WebSockets blocked. No owner browser session, account, credentials, private fixtures, uploads or purchases.
- Only the named public controls and synthetic values were used. Screenshots and compact request observations were retained as review evidence.
Individual checks and observations
Public document response
passPublic HTTP response: Navigate to the recorded public target in a fresh anonymous browser.
Observed: The sampled document returned HTTP 200 over HTTPS. Its response body SHA-256 was 0ef7aed28e1c7969902251e87a4fe3c2cc5659524ac70abed2507563e3890996; this fingerprints only the recorded HTML response.
Keyboard checklist toggle
passPublic browser sample: Focus the plain-language checkbox in a fresh anonymous browser; press Space twice.
Observed: The checkbox changed false → true → false. The page contained 64 checkbox controls; only this control was exercised.
Primary-source scope review
passSource review: Read the official pages and relevant repository or standard references linked below.
Observed: Reviewed the project’s purpose, checklist coverage and W3C’s current note that Parsing 4.1.1 was removed from WCAG 2.2.
Broader workflow and assurance coverage
not-runPublic browser sample: Keep authenticated, installation, private-data and broader accessibility workflows outside this bounded pass.
Observed: No application audit, screen-reader session, checklist persistence test or full traversal of all 64 controls was performed.
Security findings and boundaries
Passive observation of the sampled public pages, response headers and request destinations, plus the specific documented boundaries below. No intrusive scanning or security certification.
Observed · info
Small sampled request surface
The checklist sample requested its own origin and a Google Cloud Storage asset origin. No non-GET request or page error was observed during this bounded interaction.
Observed · info
HTTPS response hardening
The sampled checklist response included Strict-Transport-Security with max-age 31536000. This describes one response and does not establish an application-wide security posture.
Practical advice · caution
Keep review evidence in your own system
The public checkbox is a learning aid. Record actual findings, affected pages and sensitive screenshots in an approved internal review system rather than treating this public page as a team evidence store.
Practical caveats
- Use the checklist to generate work, then record verifiable findings and owners.
- Map the chosen checks to the current standard and product scope; do not infer conformance from a filled checklist.
What remains untested
- No application audit, screen-reader session, checklist persistence test or full traversal of all 64 controls was performed.
- One browser, one viewport and a short observation window; no cross-browser, assistive-technology or complete accessibility audit.
- Proposed use-case examples in this review were not implemented as a production workflow.
Security limits
- No backend, authenticated authorization, session isolation, vulnerability exploitation, dependency scan or account-data retention assessment was performed.
- The GET/HEAD-only guard can change hosted behavior; blocked background traffic is reported rather than treated as a product defect. Request observations are a bounded sample, not proof of all data handling.
Evaluation sources
Follow the evidence
Sources and further reading.
Keep exploring
More in evidence.
Documentation reviewed
abtest.design
Use reported experiments to form a better hypothesis.
Documentation reviewed
WebAIM Contrast Checker
A focused way to check a foreground/background pair before an attractive color choice becomes unreadable text.
Documentation reviewed
Inclusive Components
An explanation-first reference for understanding the semantics and keyboard decisions inside familiar interface patterns.