WCAG Accessibility Checklist — Meeting AA Standards

The Web Content Accessibility Guidelines version 2.2 at Level AA is the internationally recognised standard for making websites usable by people with disabilities. Meeting WCAG AA is not just about compliance or avoiding legal risk. It improves your SEO, broadens your audience and creates a better experience for every visitor, regardless of ability.

This checklist gives you the specific requirements and testing methods for each WCAG 2.2 AA criterion. It is designed to be practical and actionable. Each section covers a specific requirement, explains why it matters, gives you the exact pass condition and tells you how to test it. Use this as your reference when building or auditing a website.

What WCAG is

WCAG is a set of technical standards published by the World Wide Web Consortium, the same organisation that maintains HTML and CSS standards. The guidelines are organised around four principles: content must be perceivable, operable, understandable and robust. Each principle contains success criteria that define specific, measurable requirements for accessibility.

WCAG 2.2 was published in October 2023 and adds new success criteria that address modern interaction patterns. The new criteria cover focus appearance, dragging movements and accessible authentication. If you are building or updating a website in 2026, you should target WCAG 2.2 AA as your baseline.

The three conformance levels are A, AA and AAA. Level A is the minimum set of requirements. Level AA includes all Level A criteria plus additional criteria that address the most common accessibility barriers. Level AAA includes all criteria from both lower levels plus the strictest requirements, which are not achievable for all types of content. Level AA is the target for most organisations and is referenced by most accessibility regulations worldwide.

Why accessibility matters

Legal compliance. While Bahrain does not currently have specific web accessibility legislation, many countries do. The European Accessibility Act, the UK Equality Act, and various US state laws including California and New York reference WCAG standards. If your business serves international clients or operates in regulated industries, accessibility compliance is a legal requirement, not an option.

SEO benefits. Many WCAG success criteria overlap directly with SEO best practices. Proper heading structure helps search engines understand your content hierarchy. Descriptive link text improves both accessibility and anchor text relevance. Image alt text is used by both screen readers and search engine crawlers. Implementing WCAG AA typically improves search visibility as a side effect.

User experience for everyone. Accessibility improvements benefit all users, not just those with permanent disabilities. High colour contrast helps users viewing your site in bright sunlight. Keyboard navigation helps power users who prefer keyboard shortcuts. Captions on videos help users in noisy environments or quiet public spaces. Good accessibility is good UX.

Market reach. Globally, over one billion people have some form of disability. In Bahrain and the Gulf, where the population includes a significant number of older adults and expatriates with varying levels of digital literacy, accessible design expands your potential audience and demonstrates inclusive business practices.

Colour contrast

WCAG 2.2 AA requires a minimum contrast ratio of 4.5 to 1 for normal text and 3 to 1 for large text. Large text is defined as 18 pixels bold or 24 pixels regular weight or larger. These ratios apply to text against its background colour, including text placed on images, gradients or coloured backgrounds.

The contrast ratio measures the difference in luminance between the foreground text and the background colour. A ratio of 4.5 to 1 means the lighter colour is 4.5 times brighter than the darker colour. This ensures that users with moderate visual impairments can read the text without strain.

Test it. Use a colour contrast analyser such as the WebAIM Contrast Checker, the built-in contrast checker in Chrome DevTools or the Axe browser extension. Enter the foreground and background colour values in hex, RGB or HSL format. The tool reports the contrast ratio and shows whether it passes or fails each WCAG level.

Fix it. If your contrast ratio is too low, darken the text colour or lighten the background colour. Light grey text on a white background is the most common contrast failure. Change the text to a darker shade of grey or black. For brand colours that do not meet the minimum ratio, reserve them for decorative elements and use compliant colours for text.

Keyboard navigation

Every interactive element on your website must be operable with a keyboard alone. Users who cannot use a mouse rely on the Tab key to move between links, buttons and form fields. The tab order must follow the visual reading order, and every interactive element must display a visible focus indicator that meets contrast requirements.

Test it. Close your mouse, put it aside and navigate your entire website using only the Tab key, Shift+Tab to go backwards, Enter to activate links and buttons, and arrow keys for lists and menus. Every link, button, form input and custom widget must receive keyboard focus. The focus indicator must be clearly visible against every background it appears on.

Fix it. Remove tabindex values greater than 0, which create non-standard tab orders. Ensure custom interactive components have appropriate ARIA roles and keyboard event handlers. Style the focus indicator with a visible outline or ring that contrasts with the background. Never use outline: none without providing an alternative focus style.

Alt text and non-text content

All images, icons, charts and other non-text content must have a text alternative that conveys the same information. The alt text should describe the content and function of the image, not its appearance. Decorative images that add no information must have an empty alt attribute so screen readers skip them entirely.

Test it. Run a screen reader such as VoiceOver on macOS or NVDA on Windows. Navigate through the page and listen to what the screen reader announces for each image. Informative images should have meaningful alt text. Decorative images should be announced as decorative or skipped entirely.

Fix it. Add descriptive alt text to every informative image. For product photos, describe the product: Black leather office chair with armrests, not just Office chair. For charts and graphs, provide the data or a summary of the trend. For decorative images such as background patterns or decorative dividers, use alt with an empty string.

Form labels and error messages

Every form input must have a visible label that is programmatically associated with the input element using the HTML label element with the for attribute or using ARIA labelling. Error messages must be specific, descriptive and appear in close proximity to the field they relate to. Users must be able to understand what went wrong and how to fix it.

Test it. Submit forms with empty required fields, invalid data and incorrectly formatted input. The error messages should identify the specific field and explain what the user needs to change. Screen readers should announce the error automatically when the field receives focus or when ARIA live regions are used.

Fix it. Associate every input with a label element using for and id attributes. Position error messages immediately after the related input field. Use aria-describedby to link error messages to their inputs. Never hide labels visually; use visually hidden text that remains available to screen readers if needed.

Heading structure

Headings must follow a logical hierarchy without skipping levels. The page should have exactly one H1 that describes the main content or purpose of the page. H2s divide the page into major sections. H3s divide H2 sections into subsections. Skipping from H2 to H4 without an H3 in between is a failure.

Test it. Use the WAVE browser extension, the Axe DevTools or the HeadingsMap extension to view the heading outline of your page. The outline should form a logical tree with no gaps. Every heading should contain descriptive text that tells the user what content follows.

Fix it. Review your page content and assign headings according to the semantic hierarchy. Do not use headings purely for visual styling. If you need a certain visual appearance that does not match the heading level, use CSS to style the heading or use a span with matching visual styles within the appropriate heading element.

ARIA landmarks

ARIA landmark roles identify major regions of a page to help screen reader users navigate quickly. Landmark roles include navigation, main, complementary, contentinfo, search, form and banner. Using semantic HTML elements such as nav, main, aside, footer and header automatically provides the correct landmark roles without any ARIA attributes.

Test it. Use a screen reader to navigate the page using landmark navigation shortcuts. VoiceOver on macOS uses the rotor to list landmarks. NVDA on Windows uses the d key to move between landmarks. Every major region of your page should be identifiable as a landmark.

Fix it. Replace generic div elements with semantic HTML5 elements. Use nav for navigation blocks, main for the primary content, aside for complementary content, footer for footer content and header for introductory content. For custom widgets that do not have native HTML semantics, add appropriate ARIA roles.

Testing tools and process

WAVE. A browser extension developed by WebAIM that highlights accessibility issues directly on the page using icons and tooltips. It is free and provides an immediate visual audit that is easy to interpret. WAVE shows the heading structure, landmark regions, contrast issues and missing alt text.

Axe DevTools. A browser extension and automated testing library from Deque Systems. It runs comprehensive automated tests and categorises issues by severity. Axe integrates with continuous integration pipelines and automated testing frameworks for regression testing.

Lighthouse. Built into Chrome DevTools, Lighthouse includes an accessibility audit. It provides a score from 0 to 100 and lists every issue with guidance on how to fix it. While Lighthouse is not as thorough as WAVE or Axe, it is a useful quick check.

Manual testing process. Automated tools miss 50 to 70% of accessibility issues. Complement automated tests with manual keyboard navigation and screen reader testing. Use the WCAG-EM methodology to select a representative sample of pages. Test on multiple browsers and devices, including mobile. Document issues with screenshots and exact WCAG criteria references.

Accessibility is not a feature that you add at the end of a project. It is a design principle that should be integrated from the start of every web project. When accessibility is considered from the beginning, it adds minimal cost and effort. Retrofitting accessibility to an existing site is significantly more expensive and time-consuming. If you are planning a new website or a redesign, include WCAG AA compliance in the requirements from day one and budget for it accordingly.

The business case for accessibility goes beyond compliance and legal risk. Accessible websites reach a larger audience, including the estimated 15% of the global population who live with some form of disability. In Bahrain and the Gulf, where the population includes a growing number of older adults, accessible design ensures that your website serves the widest possible demographic. Every percentage point of additional audience reach translates directly into business growth.

Accessibility also reduces maintenance costs over time. Semantic HTML, proper heading structures and well-labelled forms are easier to maintain, update and restructure. When every element has a clear purpose and relationship to other elements, developers spend less time figuring out how the code works and more time improving it. Clean, accessible code is inherently more maintainable code.

Finally, accessibility improves your site resilience. Semantic HTML with proper structure works correctly in older browsers, text-only browsers and emerging technologies like voice assistants and AI-powered browsing tools. An accessible site is future-proof in ways that a visually designed but structurally weak site is not.

Training your team on accessibility is an investment that pays ongoing dividends. Developers, designers and content creators all need to understand the accessibility principles relevant to their work. Developers need to know how to write semantic HTML and implement ARIA correctly. Designers need to understand colour contrast, focus indicators and touch target sizes. Content creators need to write descriptive link text and meaningful image alt text. A team that understands accessibility produces compliant work without requiring audits and fixes after the fact.

Accessibility testing should be integrated into your development workflow rather than done as a separate exercise at the end of the project. Add automated accessibility checks to your continuous integration pipeline so that every code change is tested for accessibility regressions. Use tools like axe-core or Pa11y that can be run programmatically in your build process. Catch accessibility issues early when they are cheap to fix rather than late when they require significant rework.

Keep documentation of your accessibility efforts and test results. If you ever need to demonstrate compliance for legal or contractual purposes, having a record of your testing process and remediation work is invaluable. Document which pages were tested, which tools were used, what issues were found and how each issue was resolved. This documentation also helps when onboarding new team members who need to understand your accessibility standards and processes.

Engage with users with disabilities as part of your testing process if possible. Real user feedback reveals issues that automated tools and even expert manual testing can miss. Users who rely on assistive technology daily have insights into practical usability that cannot be replicated by testing alone. Consider forming a user research panel that includes people with different types of disabilities and include them in your testing cycle for major redesigns or new feature launches.