Checklist · Stacks and tools
Web Accessibility Checklist
Opens with creditsA release checklist for making a website or web app usable with a keyboard, a screen reader, zoom and reduced motion. It follows WCAG 2.2 level AA, including the criteria new in 2.2, and every check says how much it matters and exactly how to confirm it, from page structure and focus to contrast, forms, ARIA and testing.
Written by Tauseef Fayyaz8 chapters, 46 checksAbout 25 minReviewed 13 October 2026What you will learn
8 chapters · about 25 min
1Structure and semanticsScreen reader users move through a page by its headings, landmarks and lists. These checks make sure the structure in the code matches the structure people see.6 checks · 4 min
- 1Set the page language on the html element (SC 3.1.1)
- 2Give every page a unique, descriptive title (SC 2.4.2)
- 3Use one h1 and a heading order that matches the visual layout (SC 1.3.1, 2.4.6)
- 4Mark up page regions with landmark elements
- 5Provide a skip link to the main content (SC 2.4.1)
- 6Use native buttons, links and inputs instead of clickable divs (SC 4.1.2)
6 in this chapterOpen this chapter2Keyboard and focusEverything a mouse can do must work from the keyboard, and people must always see where focus is. These checks cover the keyboard pass every release should get.6 checks · 3 min
- 1Make every function work with the keyboard alone (SC 2.1.1)
- 2Let focus leave every component with the keyboard (SC 2.1.2)
- 3Show a clearly visible focus indicator on every focusable element (SC 2.4.7)
- 4Keep focused elements from being hidden behind sticky headers and banners (SC 2.4.11)
- 5Keep the focus order the same as the reading order (SC 2.4.3)
- 6Move focus into dialogs, return it on close and reset it on route changes
6 in this chapterOpen this chapter- Images and mediaImages, icons, audio and video need a text equivalent. These checks cover alternative text, icon buttons, captions and anything that moves or flashes.7 checks · 3 minOpens with credits
- Color and contrastLow contrast text is the single most common failure on the web. These checks cover text contrast, the contrast of controls and focus rings, and meaning carried by colour alone.4 checks · 2 minOpens with credits
- Forms and errorsForms are where most people give up when a site is not accessible. These checks cover labels, instructions, errors, sign-in and the new WCAG 2.2 rules for repeated entry.7 checks · 4 minOpens with credits
- Zoom, reflow, pointers and motionMany people browse zoomed in, with larger text, on a small screen or with motion turned down. These checks make sure the layout still works when they do.7 checks · 4 minOpens with credits
- ARIA and dynamic contentARIA can fix gaps that HTML cannot, and it can also make a page much worse. These checks cover custom widgets, live updates and the rule of using native HTML first.4 checks · 2 minOpens with credits
- Testing and processAccessibility holds up only when it is checked on every release, not once a year. These checks put automated tools, manual passes and real assistive technology into your routine.5 checks · 3 minOpens with credits
About this checklist
This web accessibility checklist is what you go through before a release, or when you take over a site and want to know who it shuts out. It follows the Web Content Accessibility Guidelines (WCAG) 2.2, the current W3C Recommendation, and targets level AA, which is the level most laws and procurement rules point to. In the EU, the European Accessibility Act covers services such as e-commerce, banking and e-books, so this is no longer only a nice thing to do.
The gap is large. The WebAIM Million 2026 report, which tests the home pages of the top one million websites, found detected WCAG failures on 95.9% of them, with an average of 56.1 errors per page. The same six problems show up again and again: low contrast text, missing alternative text, missing form labels, empty links, empty buttons and a missing page language. The chapters below start with those, because fixing them removes most of what automated tools find.
Every check has a severity. A must blocks some people from using the page at all, a should makes it hard or tiring, and a nice improves the experience beyond the minimum. Every check also says how to verify it: a key to press, a zoom level to set, a tool to run or a screen reader to listen with. Automated tools catch only part of the problems, so many checks ask you to use the page the way a disabled person would.
Work through it with the page open, your keyboard in reach and the mouse pushed aside. Most checks take a few minutes each, and a small site fits in an afternoon.
Common questions
What is WCAG 2.2 and what changed from 2.1?
WCAG 2.2 is the current version of the W3C Web Content Accessibility Guidelines, a Recommendation since October 2023 and updated in December 2024. It adds nine success criteria, including Focus Not Obscured, Dragging Movements, Target Size (Minimum), Consistent Help, Redundant Entry and Accessible Authentication, and removes 4.1.1 Parsing as obsolete. Content that meets 2.2 also meets 2.1.
Which WCAG level should my website meet?
Aim for level AA. It includes all level A criteria plus the ones most people rely on, such as contrast, reflow and visible focus, and it is the level most laws and procurement rules refer to. Level AAA is a useful target for individual features, not usually for a whole site.
What is the minimum color contrast ratio for text?
WCAG 2.2 level AA requires at least 4.5:1 for normal text and 3:1 for large text, which is at least 18 point, or 14 point bold. User interface components, such as input borders and focus indicators, and meaningful graphics need at least 3:1 against adjacent colours.
Can automated tools make my site accessible?
No. Tools like axe and Lighthouse reliably find problems such as low contrast, missing alt text and missing labels, which are the most common failures on the web. They cannot judge whether alt text is accurate, whether focus order makes sense or whether a custom widget works with a screen reader, so combine them with keyboard, zoom and screen reader testing.
What is the minimum target size in WCAG 2.2?
Success criterion 2.5.8, new in WCAG 2.2 at level AA, asks for pointer targets of at least 24 by 24 CSS pixels, or enough spacing that a 24 pixel circle around each target does not overlap another. Inline links in a sentence and a few other cases are exempt.
Should I add ARIA to make my site accessible?
Only when native HTML cannot do the job. The ARIA Authoring Practices Guide warns that no ARIA is better than bad ARIA, because roles change what is announced but do not add keyboard behaviour or focus. Use a real button, link, input or dialog first, and follow an APG pattern when you must build a custom widget.
Sources (6)
Checked against these, last on 13 October 2026.
- Web Content Accessibility Guidelines (WCAG) 2.2, W3Cwww.w3.org/TR/WCAG22/
- What's New in WCAG 2.2, W3C Web Accessibility Initiativewww.w3.org/WAI/standards-guidelines/wcag/new-in-22/
- The WebAIM Million, WebAIMwebaim.org/projects/million/
- Read Me First (ARIA Authoring Practices Guide), W3C Web Accessibility Initiativewww.w3.org/WAI/ARIA/apg/practices/read-me-first/
- European accessibility act, European Commissioncommission.europa.eu/strategy-and-policy/policies/justice-and-fundamental-rights/disability/union-equality-strategy-rights-persons-disabilities-2021-2030/european-accessibility-act_en
- Understanding Success Criterion 1.4.10: Reflow, W3C Web Accessibility Initiativewww.w3.org/WAI/WCAG22/Understanding/reflow.html
Related on Sefism
Picked from the other libraries by shared topics.
Roadmaps
See allCheat sheets
See allBest practices
See all- TypeScript Best PracticesModern TypeScript best practices for 2026: strict settings, TypeScript 7, modeling data with unions, safe narrowing, runtime validation, generics and typed linting.
- Modern CSS Best PracticesModern CSS best practices: cascade layers, low specificity, custom properties, Grid and Flexbox layout, responsive design, container queries, :has() and nesting, plus Tailwind CSS v4 tips.
- Next.js App Router Best PracticesNext.js 16 App Router best practices: Server Components, Cache Components and use cache, secure Server Actions, proxy.ts, metadata and images.
Checklists
See all- Web Performance ChecklistA practical web performance checklist built on Core Web Vitals: LCP, INP and CLS, with a severity and a concrete way to verify every check.
- Web Application Security ChecklistA practical web application security checklist built on the OWASP Top 10:2025 and ASVS 5.0, with a severity and a way to verify every check.
- Developer Portfolio Website ChecklistCheck your developer portfolio site end to end: clear intro, 3 to 5 strong projects, live demos and code, speed, accessibility, SEO basics, custom domain, contact, analytics and upkeep.
Project structures
See all- MERN (MongoDB, Express, React, Node) project structureOne repository with a React app built by Vite in client/, an Express API with Mongoose in server/, and a tiny shared/ package that both import for request shapes and types. npm workspaces give you one install and one command to run both, and one example feature (clinic appointments) runs through every folder so you can see how a request travels from a form to MongoDB and back, and what tests, security and operations a real team adds around it.
- Next.js full stack (database and auth) project structureOne Next.js app that is both your frontend and your backend: pages render on the server, forms call Server Actions, and Route Handlers serve the few real HTTP endpoints (auth, webhooks, jobs, health). PostgreSQL through Prisma ORM, sign-in through Better Auth, background jobs with Inngest, and every database read goes through a small Data Access Layer that checks who is asking. The example features are invoices and clients for freelancers.
- .NET with Angular project structureThe common enterprise pairing: an ASP.NET Core Web API and an Angular app as two projects in one solution, exactly as the Visual Studio template lays them out. In development the Angular dev server proxies API calls to .NET; in production the API serves the built Angular files from one origin, so cookie sign-in with ASP.NET Core Identity just works. The Angular API client is generated from the API's OpenAPI document, so both sides always agree. The example features are orders and products.
Career questions
See all- What should I learn to become a web developer, and in what order?Learn the web platform first (HTML, CSS, JavaScript, how HTTP works), then one frontend framework, then a backend with a database, and build a real project at each stage. If you already know WordPress, you are not starting over: your HTML, CSS and PHP experience transfers.
- How do I choose between frontend, backend, mobile, cloud, cybersecurity, data and AI without trying them all for years?Do not try to pick the best field; pick the one whose daily problems you can tolerate on a bad day. Run a short, cheap experiment in two or three candidates, compare what you enjoyed doing rather than what sounded exciting, check the local job market, and commit for six to nine months.
- Should I become an AI engineer or stay a full stack developer?For most full stack developers this is not an either/or. AI engineering is largely full stack engineering plus models, evaluation and data. Keep your full stack strength, add AI features to real work, and move titles only when you have shipped AI work you can point to.
Stuck on something specific?
Writing only gets you so far. If you want an answer to your situation rather than the general case, book a session and we will work through it together. Sessions are free for approved Sefism members, and a few slots open each week.
- 1:1 Mentorship
- Fresh Graduate Mentorship
- Career Guidance
Brand deals, promos and partnerships: tauseeffayyaz@gmail.com