How can we help?

AAI combines automated accessibility scanning with workflows for human testing, developer remediation, retesting and evidence. Automated checks identify conditions that software can detect reliably, while manual testing covers important behaviours that require human judgement.

No. Automated scanning can detect many important technical failures, but it cannot reliably assess every WCAG requirement or every real-world interaction. Full accessibility assurance requires appropriate human testing as well.

Automated scanning uses software rules to detect testable technical conditions quickly. Manual auditing uses a human tester to evaluate behaviours such as keyboard interaction, focus order, meaningful content, assistive-technology behaviour and complete user journeys.

WCAG is the Web Content Accessibility Guidelines published by W3C. Level AA is a widely used target for digital accessibility. AAI uses standards profiles and evidence to help organisations assess relevant accessibility requirements.

Domain verification helps ensure that AAI scanning is performed only by people who are authorised to assess the website. It is an important security and responsible-use safeguard.

Add and verify your domain, discover or add the pages you want to manage, open Scan Central and start a scan for the selected pages. If pages require authentication, configure Secure Scan Access first.

Scan duration depends on the number and complexity of pages, site response times and whether protected access is involved. Larger assessments naturally take longer than a small group of pages.

Yes. AAI can discover crawlable pages and let you review them before deciding which URLs should become actively Managed Pages.

Common causes include navigation that is not crawlable, anti-bot protection, pages that require authentication, robots restrictions or a site whose links are generated dynamically. Important URLs can also be added or handled through an appropriate secure scanning configuration.

Yes. Bot-management services can prevent an authorised scanner from loading pages even though the website works normally in a person's browser. The site's administrator may need to allow the AAI scanning workflow or use another approved scanning approach.

Yes, where an appropriate Secure Scan Access method has been configured and the organisation has authorised AAI to access those pages.

It means an automated accessibility rule detected a condition that did not satisfy that rule. The evidence should be reviewed in context, particularly where human judgement is still required.

Not necessarily. A repeated component can generate similar failures on many pages, while one user-facing accessibility barrier may involve several technical conditions. Evidence should therefore be interpreted in context.

Because the assessment scope increased. If the same inaccessible component appears on additional pages, scanning those pages can legitimately produce additional failure records.

Automation cannot reliably judge every accessibility requirement. Keyboard behaviour, reading order, focus management, meaningful instructions and many assistive-technology interactions require human evaluation.

A person with the required accessibility testing competence and permission within the AAI workspace. Some assessments may also benefit from specialist assistive-technology or lived-experience testing.

It means the tester does not yet have enough confidence or evidence to make the final accessibility decision and wants the item reviewed by an appropriate person.

Use Not Applicable only when the requirement genuinely does not apply to the page, component or scenario being tested. It should not be used simply because a test is difficult to complete.

Yes. Notes, evidence references and supporting material should be recorded so another qualified person can understand how the result was reached.

A Developer Action is a structured remediation task created from accessibility evidence. It gives development teams a clear piece of work that can later be reviewed and retested.

The affected requirement should be retested. The work should only be considered resolved when the retest provides evidence that the original accessibility problem has actually been fixed.

It represents work that has been remediated and now needs accessibility verification before it can be treated as resolved.

A Test Plan defines what should be tested. A Test Run records what happened when that plan was actually executed.

A Test Case is a reusable description of a test, including the steps to perform and the expected outcome.

Yes. Reusability is one of their main benefits. A Test Case can be included in different plans or repeated across releases while still producing separate execution evidence.

Yes. Where the failure represents remediation work, it can be passed into the developer workflow so that the evidence and subsequent fix remain connected.

Generate a report when you need a point-in-time record of the assessment evidence — for example after an audit milestone, remediation cycle, management review or procurement request.

Yes. Because accessibility evidence changes over time, later reports can reflect subsequent testing and remediation activity while earlier reports remain useful historical records.

It is a public-facing explanation of a digital service's accessibility, known limitations and relevant support or feedback arrangements. Claims should accurately reflect the evidence available.

No. The widget provides optional user-controlled adjustments, but it does not repair inaccessible source code and does not replace scanning, manual testing, remediation or verification.

AAI is designed around scoped access. Assign the developer only to the organisation and domain required for their work and give them the least privilege needed.

Visible options depend on package entitlements, organisation and domain membership, role permissions and sometimes the current domain context.

No. Use a dedicated testing account with only the permissions needed to reach the assessment scope. Highly privileged production administrator credentials should not be used for routine scanning.

The Secure Scan Access configuration may need to be updated. Authentication profiles should be retested whenever login URLs, form fields, tokens or authentication behaviour change.

Check that the domain is verified, pages are selected correctly, the website is reachable and there is no authentication or anti-bot barrier preventing the scan from beginning.

Your browser may have login cookies, trusted-device state or other session information that AAI does not possess. Bot-management services can also treat automated access differently from normal browser traffic.

The change may not have fully addressed the original accessibility requirement, the affected component may exist elsewhere, cached or deployed code may differ from the developer's environment, or the remediation may have introduced another failure.