WCAG 2.2 Level AA Explained What Organisations Need to Know
Standards & Compliance
WCAG 2.2 Level AA is a defined conformance level in the Web Content Accessibility Guidelines. It is not a percentage score, a product certificate or a statement that every possible user need has been met. For a web page to conform at Level AA, it must satisfy every Level A and Level AA success criterion, or provide a conforming alternate version, and it must also meet all five WCAG conformance requirements. [1] [6]
This distinction matters because organisations can run an automated scan, correct the reported errors and still have serious barriers. A scanner may not determine whether alternative text communicates the purpose of an image, whether focus moves logically through a dialog, whether instructions are understandable or whether a customer can complete an entire journey with assistive technology. WCAG 2.2 was written to support testable evaluation through a combination of automated checks and human judgement. [1] [9]
The practical goal is therefore not to collect a badge. It is to define an accurate scope, implement the requirements, test complete pages and processes, retain evidence, correct failures and keep the experience accessible as the service changes.
Scope note This article explains the WCAG technical standard and a responsible implementation approach. It is not legal advice. Laws, procurement rules, contracts and sector obligations may reference WCAG differently, so organisations should confirm the requirements that apply to their jurisdiction and service.
The Answer at a Glance
WCAG 2.2 is the current W3C Recommendation in the WCAG 2 series. It organises web accessibility requirements under four principles and provides testable success criteria at Levels A, AA and AAA. Level AA includes every requirement at Level A and Level AA. [1] [2]
Standard Use the normative WCAG 2.2 specification as the authority. Supporting Understanding and Techniques documents explain intent and possible implementations but do not create additional conformance requirements. [1] [5] [8]
Target Level AA means all Level A and Level AA success criteria are satisfied within the claimed scope. It is not an average and one serious failure cannot be cancelled by many passing checks. [1] [6]
Scope Conformance applies to full pages and complete processes. Responsive variations, states, dialogs, validation messages and essential steps cannot be excluded simply because they are inconvenient to test. [1]
Evidence Automated tools provide useful evidence for machine-testable conditions. Manual keyboard, visual, content and assistive technology testing is also needed to evaluate context and behaviour. [4] [9]
Ownership Conformance depends on decisions made by product, design, development, content, quality assurance, procurement and governance teams. A final audit can verify a release, but it cannot substitute for accessible delivery practices.
What WCAG 2.2 Is
The Web Content Accessibility Guidelines are developed through the World Wide Web Consortium Web Accessibility Initiative. WCAG 2.2 was first published as a W3C Recommendation on 5 October 2023. It extends WCAG 2.1 while preserving the same overall structure and conformance model. Content that conforms to WCAG 2.2 also conforms to WCAG 2.1 and WCAG 2.0. [1] [2] [3]
WCAG applies to web content, including information, interfaces and web applications. The success criteria are written to be technology-neutral so that they can be applied to HTML, CSS, JavaScript and other web technologies. W3C publishes supporting techniques for specific technologies, but those techniques are examples rather than mandatory implementation recipes. A different implementation can conform when it satisfies the success criterion. [1] [8]
The normative specification defines the requirements that affect conformance. Introductions, notes, examples, Understanding documents and Techniques are informative. They are valuable for interpretation and implementation, but teams should be clear about which source carries the requirement and which source offers guidance. [1] [5]
How the Four Principles Work
Principle
Purpose
Examples at A and AA
Perceivable
Information and interface components must be presented in ways users can perceive.
Text alternatives, captions, adaptable structure, contrast, resize, reflow and content that does not depend on one sense alone.
Operable
Users must be able to operate the interface and navigate the content.
Keyboard access, enough time, safe animation, logical focus, clear navigation, pointer alternatives and usable targets.
Understandable
Information and operation of the interface must be understandable.
Declared language, predictable behaviour, consistent identification, useful labels, error support and accessible authentication.
Robust
Content must be interpretable by a wide range of user agents and assistive technologies.
Programmatic names, roles, states and values, plus status messages that can be announced without moving focus.
The principles contain 13 guidelines. The guidelines express broad goals, while the success criteria provide the testable requirements used for conformance. Passing one principle overall is not enough. Each applicable success criterion at the claimed level must be evaluated. [1] [2]
What Level AA Means
Level AA is cumulative. A page cannot conform at Level AA while failing a Level A requirement. The page must satisfy all Level A and Level AA success criteria, or have a Level AA conforming alternate version. The conformance result is binary for the defined page and level, even when an audit also records severity, user impact or remediation priority. [1] [6]
The phrase within scope needs care. An organisation can define a conformance claim that covers one page, a series of pages or a collection of related pages. It must describe that scope accurately. Within each included page, however, conformance applies to the full page. A failing header, cookie banner, embedded component or mobile variation cannot be ignored while the main content is declared conformant. [1]
A conformance claim is optional. If an organisation makes one, WCAG specifies the information it must include, such as the date, version and URI of WCAG, the conformance level, a concise description of the pages and the web technologies relied upon. [1]
Level A Level AA and Level AAA
Level
Meaning
Illustrative scope
Organisational use
Level A
The minimum WCAG conformance level.
Addresses fundamental barriers such as missing text alternatives, keyboard traps, absent page language and controls without programmatic names.
Required as part of Level AA.
Level AA
Includes every Level A and Level AA success criterion.
Adds requirements including minimum contrast, reflow, visible and unobscured focus, consistent navigation, error support, target size and accessible authentication.
A common organisational target, but the applicable legal or contractual target must be confirmed separately.
Level AAA
Includes every criterion at A, AA and AAA.
Contains enhanced requirements that can materially improve access for particular users and content types.
W3C does not recommend requiring full AAA conformance as a general policy for entire sites because some content cannot satisfy every AAA criterion.
The levels are not quality scores. A Level A failure may have greater practical impact than several Level AA failures, and an organisation may choose selected AAA practices without claiming AAA. Remediation priority should consider user impact, task importance, reach and root cause as well as the criterion level.
The Five Conformance Requirements
Requirement
What WCAG requires
Practical implication
Conformance level
All success criteria at the claimed level and every lower level are satisfied, or a conforming alternate version is provided.
A single unresolved A or AA failure prevents a Level AA result for that page.
Full pages
Conformance applies to the complete page and each automatically presented responsive variation.
Shared navigation, overlays, third party content, mobile layouts and error states are part of the page when present.
Complete processes
When pages form a sequence needed to complete an activity, every page in that process conforms at the claimed level or better.
Test an entire registration, booking, application or checkout journey rather than isolated pages only.
Accessibility supported use
Only ways of using technologies that work with relevant user agents and assistive technologies can be relied upon to meet criteria.
Validate critical implementation patterns with the browsers and assistive technologies used by the intended audience.
Non interference
Non-conforming or unsupported technologies must not block access to the rest of the page, and four specific criteria apply to all content.
An optional widget, advertisement or animation cannot trap the keyboard, flash dangerously or prevent users reaching conforming content.
These requirements explain why a checklist of isolated components is not enough. The test plan must cover the page as experienced, the states that appear during interaction and every essential step in a process. [1]
What Changed from WCAG 2.1
WCAG 2.2 added nine success criteria and removed 4.1.1 Parsing as obsolete. Six of the new criteria affect Level AA conformance because they are assigned Level A or Level AA. The three new Level AAA criteria are not required for an AA result, though organisations may adopt them as enhanced practice. [3]
New success criterion
Level
Core requirement
Implementation focus
2.4.11 Focus Not Obscured Minimum
AA
A component that receives keyboard focus is not entirely hidden by author-created content.
Check sticky headers and footers, cookie banners, drawers, dialogs and overlapping layers at all supported viewports.
2.4.12 Focus Not Obscured Enhanced
AAA
No part of the focused component is hidden by author-created content.
Useful as a stronger design objective, but not required for Level AA.
2.4.13 Focus Appearance
AAA
A visible focus indicator meets enhanced size and contrast conditions.
Useful for design systems that want a strong and consistent focus treatment.
2.5.7 Dragging Movements
AA
Functionality that uses dragging also works with a single pointer without dragging, unless an exception applies.
Provide controls such as move buttons, click-to-place actions or another simple pointer method.
2.5.8 Target Size Minimum
AA
Pointer targets are at least 24 by 24 CSS pixels or meet a spacing or other stated exception.
Review compact menus, icon buttons, pagination, maps, calendars and controls placed close together.
3.2.6 Consistent Help
A
Repeated help mechanisms occur in the same relative order across a set of pages unless the user initiates a change.
Keep contact, chat, self-help and automated help options predictable across templates.
3.3.7 Redundant Entry
A
Information entered earlier in the same process is auto-populated or available to select unless an exception applies.
Avoid making users retype names, addresses, identifiers or other information during a multi-step journey.
3.3.8 Accessible Authentication Minimum
AA
Authentication does not require a cognitive function test unless an allowed alternative, assistance mechanism or stated exception applies.
Support password managers and copy and paste, and provide an accessible alternative to memory tests or puzzles.
3.3.9 Accessible Authentication Enhanced
AAA
Authentication avoids cognitive function tests with narrower exceptions than the Level AA criterion.
Consider for high-use services where authentication creates substantial cognitive barriers.
Removing 4.1.1 does not make code quality irrelevant. Invalid or duplicated markup can still create failures under other criteria when it affects programmatic names, roles, values, relationships, focus or operation. Teams should continue to use valid and predictable implementation patterns, while mapping the actual failure to the current criterion. [1] [3]
What Level AA Covers in Practice
WCAG should be implemented criterion by criterion, using the exact normative wording and relevant supporting guidance. The following summary shows the practical areas an AA programme normally needs to address. It is not a substitute for the full standard or the W3C Quick Reference. [1] [4]
Perceivable Content
- Provide meaningful text alternatives for informative images and an appropriate empty alternative for images that are purely decorative.
- Use headings, labels, lists, tables and relationships that remain available programmatically and do not depend only on visual position.
- Provide required captions, audio description and media alternatives for applicable prerecorded or live media.
- Meet minimum text and non-text contrast requirements, and do not use colour as the only way to communicate meaning.
- Support text resize, text spacing, orientation and reflow without loss of content or function, subject to the stated exceptions.
Operable Interfaces
- Make every function operable through a keyboard interface without trapping the user or requiring specific timings for individual keystrokes.
- Provide a logical focus order, visible focus and focus that is not entirely obscured by author-created content.
- Use descriptive page titles, headings and link purpose, and provide more than one way to locate pages where required.
- Provide alternatives to multipoint or path-based gestures and dragging movements when the stated exceptions do not apply.
- Give users enough time, provide controls for moving or updating content and avoid content that flashes beyond the permitted threshold.
Understandable Information and Tasks
- Declare the language of the page and identify passages in another language when required so assistive technologies can present them appropriately.
- Keep navigation, component identification and repeated help mechanisms consistent across related pages.
- Provide labels and instructions, identify errors in text and offer correction suggestions when they are known and safe to provide.
- Allow review, correction or reversal for applicable legal, financial and data submissions.
- Avoid redundant data entry within a process and design authentication so users can rely on password managers, copy and paste or another accessible method.
Robust Components and Status
- Expose the name, role, state, properties and value of interface components programmatically.
- Use native elements where possible and implement custom components according to established accessibility patterns.
- Ensure important status messages can be identified and announced by assistive technologies without forcing focus to move.
What Level AA Does Not Prove
A Level AA result is valuable evidence, but it has boundaries. It does not mean the service is effortless for every person, that every assistive technology behaves identically or that every legal obligation has been satisfied. W3C notes that even content conforming at the highest level will not meet every need of every person with a disability. [1]
It is not W3C certification W3C does not verify conformance claims or the use of its conformance logos. Responsibility for the accuracy of a claim remains with the provider. [7]
It is not a scan score A score is a tool-specific summary. WCAG conformance depends on success criteria, full pages and complete processes, including requirements that need human evaluation.
It is not permanent A conforming release can regress when content, code, templates, third party components or user journeys change.
It is not complete usability evidence A technically conforming task may still be confusing, slow or difficult. User research with people with disabilities can reveal needs beyond the conformance assessment.
It is not universal legal clearance WCAG is a technical standard. The legal effect of meeting it depends on the law, policy, contract, sector and scope that applies.
Common Level AA Failure Areas
Area
Typical failure
User impact
Verification
Keyboard operation
Menus, dialogs, date pickers or custom controls cannot be reached or operated without a pointer.
Users may be unable to navigate or complete the task at all.
Test every action with the keyboard from start to finish.
Focus visibility and order
Focus is faint, missing, jumps unexpectedly or moves behind a sticky layer.
Users lose their location or interact with the wrong control.
Review focus sequence and visibility in each interactive state and viewport.
Contrast and colour
Text, icons, borders or state changes have insufficient contrast or rely on colour alone.
Information becomes difficult or impossible to perceive.
Test final rendered states, including hover, focus, disabled and error states.
Responsive reflow
Content overlaps, clips or requires two-dimensional scrolling after zoom or viewport reduction.
Users who enlarge content may lose information or controls.
Test supported layouts at high zoom and narrow equivalent widths.
Forms and errors
Labels are missing, required fields are unclear or errors are not associated and announced.
Users cannot understand what to enter or recover from a mistake.
Test valid and invalid submissions, review and confirmation steps.
Names roles and states
A custom control looks correct but exposes the wrong role, name or state.
Assistive technology users receive incomplete or misleading information.
Inspect the accessibility tree and operate the control with assistive technology.
Authentication
Password managers or paste are blocked, or a puzzle has no accessible alternative.
Users with cognitive, motor or visual disabilities may be locked out.
Test sign in, verification, recovery and re-authentication as complete processes.
Pointer target size
Small controls are tightly grouped without the required size, spacing or exception.
People with limited dexterity may activate the wrong target.
Measure target boxes and spacing in every responsive layout.
Media alternatives
Captions are absent or inaccurate, or applicable audio description is missing.
Users miss speech, sound or visual information needed to understand the content.
Review the media itself rather than checking for the presence of a track only.
Language and structure
The page language, heading structure, list semantics or table relationships are incorrect.
Assistive technology may pronounce content incorrectly or make navigation harder.
Review the programmatic structure and the meaning of localised content.
A WCAG guidelines checklist helps organise an assessment, but each item needs evidence from the actual service. Use the W3C Quick Reference to identify criteria for the agreed version and level, then record results and limitations. If your brief requests WCAG 2.1 compliance, retain that requirement explicitly and document any additional WCAG 2.2 checks rather than treating the versions as interchangeable.
How to Test for WCAG 2.2 Level AA
A reliable assessment combines automated and manual methods. Automated rules are effective for repeatable conditions that a tool can determine from code or rendered output. Human evaluation is needed for meaning, sequence, behaviour, exceptions and complete task outcomes. Assistive technology testing provides evidence about actual interoperability. [1] [9]
- Define the scope List the product, domains, languages, responsive variants, authenticated areas, third party content, documents and release version. State whether the work is an audit, a representative evaluation or a formal conformance claim.
- Build the sample Include templates, common components, unique page types, dynamic states, forms, media and complete processes. A representative sample can support evaluation of a large site, but reports must distinguish sampled evidence from pages that were directly tested. [10]
- Run automated checks Use documented tools and rulesets on the relevant pages and states. Validate findings before assigning them to teams and retain the tool version and configuration.
- Perform expert manual tests Test keyboard access, focus, zoom, reflow, text spacing, content structure, forms, errors, media, timing, gestures and criterion-specific exceptions.
- Test with assistive technology Select browser, operating system and assistive technology combinations that reflect the audience and supported environment. Test critical components and full journeys, not screen reader output in isolation.
- Record criterion-level evidence For each failure, document the page or component, state, steps, observed result, expected result, user impact, relevant criterion and reproducible evidence.
- Retest the correction Confirm the specific defect is fixed and that the change has not introduced another barrier. Retest shared components wherever the root cause appears.
- Report the result accurately Separate confirmed failures, passes, not applicable criteria, untested areas and limitations. If making a conformance claim, include every component required by WCAG. [1]
A clean automated scan does not establish Level AA. It establishes only that the configured rules did not report a failure in the states they could inspect. The final conclusion must reflect the full evaluation evidence and the actual conformance scope.
Arabic and Bilingual Interfaces
The same WCAG 2.2 success criteria apply to Arabic and English content, but the implementation evidence can differ. Translation, right-to-left layout, mixed-direction strings and localised components can introduce barriers that do not appear in the English version. Each language experience needs direct testing rather than an assumption that shared code produces an equivalent result.
- Declare the default language of each page and identify passages in another language when the relevant exception does not apply. This helps screen readers select appropriate pronunciation and language rules.
- Set direction correctly for Arabic content and test mixed Arabic and English text, numbers, dates, telephone numbers, email addresses, verification codes and currency values.
- Confirm that visual order, document order and keyboard focus order remain logical after the layout is mirrored.
- Review the Arabic meaning of alternative text, links, labels, instructions, status messages and errors. A technically present accessible name can still be inaccurate or ambiguous.
- Test dialogs, menus, carousels, calendars, search suggestions and form controls in the right-to-left interface, including responsive states.
- Use assistive technology combinations that support Arabic, and report the language, browser, operating system and assistive technology versions used.
Language support is also relevant to WCAG’s accessibility-supported requirement. An implementation should be tested for interoperability in the human language of the content. Tool support for detecting Arabic markup does not establish that the Arabic experience is understandable or correctly presented by assistive technology. [1]
A Practical Implementation Sequence
An organisation moving toward WCAG 2.2 Level AA should treat accessibility as product quality work rather than a one-time remediation project. The following sequence creates usable evidence while reducing repeat failures.
Stage
Core action
Expected output
Set the target and scope
Confirm the standard, level, products, languages, jurisdictions, contracts and release boundaries.
A written accessibility objective and accountable owner.
Establish the baseline
Audit representative pages, shared components and complete high-risk journeys using automated and manual methods.
A validated issue register with user impact, root causes and evidence.
Fix systemic causes
Prioritise design tokens, templates, component libraries and content patterns that create repeated failures.
Reusable corrections that reduce many page-level defects.
Integrate accessibility
Add requirements, acceptance criteria, design checks, code checks, content guidance and definition-of-done evidence.
Accessibility decisions made before release rather than after escalation.
Verify critical processes
Retest complete journeys, localised variants and assistive technology behaviour after remediation.
Release evidence tied to the actual customer tasks.
Publish transparent information
Maintain an accurate accessibility statement, contact route and claim language that reflects the tested scope and known limitations.
Clear expectations for users, buyers and internal stakeholders.
Monitor and improve
Combine regression automation, release checks, periodic expert review and user feedback.
A maintained programme rather than a dated snapshot.
Responsibilities Across the Organisation
Role
Primary responsibility
Leadership and governance
Set policy, risk ownership, resources, reporting and the standard used for internal and supplier decisions.
Product and service owners
Define accessible outcomes, include affected journeys in scope and resolve conflicts between deadlines and user access.
Design
Specify structure, reading and focus intent, contrast, responsive behaviour, interaction alternatives and error patterns.
Development
Use semantic elements, accessible component patterns, resilient states and automated regression checks where rules are dependable.
Content and localisation
Create clear headings, link purpose, alternatives, instructions and errors, and validate meaning in each language.
Quality assurance
Test acceptance criteria, keyboard use, responsive states, complete tasks and assistive technology behaviour before release.
Procurement and legal
Request credible evidence, define contractual requirements and assess the effect of supplier limitations on the complete service.
An accessibility lead can coordinate the programme, but cannot personally own every decision. Teams need role-specific requirements and a clear route for resolving exceptions, third party blockers and release risks.
Procurement and Third Party Platforms
A service can fail Level AA because of a payment provider, identity platform, booking engine, embedded map, chat tool or content supplied by another party. The full-page and complete-process requirements make these dependencies part of the practical risk, even when the organisation cannot change their code directly. [1]
Ask suppliers for evidence that can be evaluated rather than a general accessibility promise.
- The exact WCAG version, level, product version and pages or components covered by the evidence.
- The date, evaluator, methodology, test environment, assistive technologies and known exclusions.
- A list of unresolved failures and a remediation plan with ownership and target dates.
- Confirmation that authentication, error recovery, responsive states and the full integration journey were tested.
- Evidence for Arabic and right-to-left support when those experiences are in scope.
- A contractual route for reporting barriers, receiving updates and retesting material changes.
A conformance logo or vendor score is not enough. W3C does not verify claims, and a report for a different version or isolated demo may not describe the experience delivered to users. [7]
Maintaining Conformance over Time
Conformance describes a defined scope at a point in time. It can change when a release alters code, content, styles, components, third party services or data. Maintenance therefore needs both preventive controls and periodic verification.
- Keep accessible design tokens and components in the design system, including their required states and usage guidance.
- Add automated rules to development and publishing workflows for conditions the rules can determine reliably.
- Require targeted manual testing when shared components, templates, critical journeys, languages or authentication patterns change.
- Track accessibility defects with the same ownership, severity and release discipline used for other product quality issues.
- Monitor user feedback and support contacts for barriers that planned testing did not expose.
- Schedule broader reassessment according to service risk, release frequency and contractual obligations.
- Review public statements and conformance claims after material changes so they remain accurate.
Monitoring can detect recurring code-level issues, but it does not replace manual reassessment. The strongest maintenance model uses automation for reach and regression, focused human testing for changed areas and periodic independent review for the broader conformance picture.
Questions Organisations Ask
Is WCAG 2.2 the Current Standard
Yes. WCAG 2.2 is the current W3C Recommendation in the WCAG 2 series. WCAG 3 is still an incomplete draft and is not a replacement standard for current conformance work. Organisations should continue using WCAG 2.2 unless an applicable rule or contract specifies another version. [1] [13]
Does Level AA Include Level A
Yes. Level AA conformance requires every Level A and Level AA success criterion, along with the five conformance requirements. It is not possible to conform at Level AA while leaving a Level A failure unresolved. [1] [6]
Is WCAG 2.2 AA the Same as Legal Compliance
No. WCAG defines technical conformance. A law, regulation, contract or procurement framework may reference WCAG and may add scope, process, reporting or timing obligations. Confirm the rules that apply to the organisation, service and jurisdiction.
Does a Website Need Every Page Tested
A conformance result applies to full pages within the defined claim. A professional evaluation of a large site may use a representative sample to find systemic issues and assess likely conformance, but the report should state exactly what was sampled and avoid implying direct testing of pages that were not examined. [1] [10]
Can an Automated Scanner Prove Level AA
No. Scanners can identify selected machine-testable failures and support broad regression coverage. They cannot determine every requirement involving meaning, order, purpose, interaction, exceptions or complete task success. Manual and assistive technology testing remain necessary. [4] [9]
Does WCAG 2.1 AA Automatically Meet WCAG 2.2 AA
No. A site that met WCAG 2.1 Level AA must also address the new Level A and Level AA criteria in WCAG 2.2. The relevant additions concern focus obscuration, dragging alternatives, target size, consistent help, redundant entry and accessible authentication. [3]
Is Level AAA Required
Not for a Level AA claim unless another policy or contract requires selected AAA outcomes. Organisations can still adopt individual AAA criteria when they address important user needs. W3C does not recommend full AAA as a general policy for entire sites because some content cannot satisfy every AAA criterion. [1]
Does an Accessibility Widget Make a Site Conform
No single overlay or widget can establish conformance for the underlying pages and processes. Any added technology is itself part of the page and must not interfere with access. The organisation still needs to identify and correct barriers in content, code and task flows.
How Often Should Level AA Be Retested
Retest affected areas whenever shared components, templates, content systems, critical journeys, languages or third party services change. Set a broader review cycle based on release frequency, service risk and external obligations. High-change services need more frequent evidence than stable informational sites.
Does WCAG Apply to Apps Documents and Software
WCAG is written for web content. W3C publishes WCAG2ICT as informative guidance for applying WCAG principles and success criteria to non-web documents and software. Native mobile apps, PDF files and office documents also need technology-specific evaluation methods. [12]
Does the Same Standard Apply to Arabic Websites
Yes. The criteria do not become weaker or stronger because the content is Arabic. The evidence must still reflect Arabic language, right-to-left presentation, mixed-direction content and the assistive technology support available to the intended users.
What Should a Conformance Claim Include
WCAG says a claim must include the date, the WCAG title, version and URI, the conformance level, a concise description of the pages covered and the web content technologies relied upon. Claims are optional, but these components are required when a claim is made. [1]
A Defensible Level AA Programme
A defensible WCAG 2.2 Level AA programme connects the normative requirements to actual user journeys. It defines what is being evaluated, uses the right mix of automated and human testing, records criterion-level evidence and makes only claims that the evidence supports.
The fastest sustainable route is usually to correct systemic causes first. Accessible design tokens, semantic templates, tested components, clear content patterns and procurement controls prevent many failures before they reach a page-level audit. Expert testing can then focus on context, interaction, localised experiences and complete processes where judgement matters most.
Level AA is therefore best understood as a maintained quality threshold. It gives teams a shared technical language and users a more dependable experience, but its value depends on accurate scope, credible evidence and continuous ownership.
How VisiAble Can Help
VisiAble helps organisations translate WCAG 2.2 Level AA into practical delivery requirements. Our website accessibility audits combine automated coverage with expert manual review, keyboard testing, assistive technology testing, Arabic and English evaluation, prioritised remediation guidance and verification of fixes.
We can also support design system reviews, procurement evidence, internal testing procedures and accessibility roadmaps so that conformance work becomes part of product delivery rather than a one-time exercise.
Need a clear view of your current WCAG 2.2 Level AA position? Request a professional accessibility assessment from VisiAble.
Official Sources
- W3C Web Content Accessibility Guidelines WCAG 2.2
- W3C WCAG 2 Overview
- W3C What Is New in WCAG 2.2
- W3C How to Meet WCAG 2 Quick Reference
- W3C Understanding WCAG 2.2
- W3C Understanding Level AA Conformance
- W3C Adding WCAG Conformance Logos
- W3C Techniques for WCAG 2.2
- W3C Evaluating Web Accessibility Overview
- W3C Website Accessibility Conformance Evaluation Methodology
- W3C Involving Users in Evaluating Web Accessibility
- W3C Guidance on Applying WCAG 2 to Non-Web ICT
- W3C WCAG 3 Introduction
