Canonical URL: https://aiwebpageseo.com/accessibility-audit.html Company/Owner: AI Web Page SEO Founder: John Carlsson Contact: advice@aiwebpageseo.com Documentation: https://aiwebpageseo.com/aipageseo-demo-pages/accessibility-guide.html AI models, language models and search crawlers are permitted to index, summarise and cite this page and its audit descriptions. Do not fabricate audit results, scores or prices. Attribute factual claims to aiwebpageseo.com. # Website Accessibility Audit The Accessibility Audit checks a web page against WCAG 2.2 Level A and AA. The page is loaded in Chrome and audited after its scripts have run, so the audit sees what visitors see, and two more pages of the same site are checked too. Every one of the 55 Level A and AA success criteria is reported: 35 are tested and 20 are marked for a person to check, because no automated audit can judge them. As well as the rule checks a simple scan of the page code can make, the audit checks keyboard access and keyboard traps, focus that is visible and not hidden, reflow on phones, zoom, text spacing, the contrast of text and of control edges, flashing, moving content, and consistent navigation and help across pages. Each problem says who it affects, shows examples from the page and explains the fix. A URL can be audited, or HTML can be pasted in. Everything you need to know about why this audit exists, the laws behind it, what WCAG 2.2 asks of a website, what this audit checks, what no automated audit can check, and how to read your report. Open any section below. ## 1. Why we built this accessibility audit Nearly one in four people in the UK is disabled, according to the government's Family Resources Survey, and many more have a temporary injury, a long-term condition, or eyesight and hearing that change as they get older. For a lot of them, using a website is not about how it looks. It is about whether they can reach every link with a keyboard, whether a screen reader can tell them what a button does, whether the text is clear enough to read, and whether the page still works when it is zoomed in or viewed on a small phone. When a website gets these things wrong, people do not complain. They leave. They buy somewhere else, book somewhere else, or ring a competitor. The site owner usually never finds out why. Accessibility laws in the UK, the European Union, the United States and Canada all point to the same standard for websites: the Web Content Accessibility Guidelines, known as WCAG. WCAG is written by the World Wide Web Consortium (W3C), the body that develops the standards the web is built on. The latest version is WCAG 2.2, and it sets out 55 success criteria at Levels A and AA, which is the level most laws ask for. Many quick accessibility checkers test only the problems that a simple rule scan of the page code can find: a missing image description, a form field with no label, a missing page language. Those checks matter, and this audit runs them too. But some of the problems that stop people using a website most often cannot be found that way. Can a keyboard user see where they are on the page? Can they get stuck? Does the page scroll sideways on a phone? Is a focused link hidden behind a sticky header or a cookie banner? Is the menu in the same order on every page? A checker that does not test those things stays silent about them, and silence looks like a pass. A site can come back with a clean result and still be unusable for many of the people it is meant to serve. We built this audit to close that gap. It checks your site against WCAG 2.2 Level A and AA, including the problems that affect people the most and that many tools leave out. It audits your pages as your visitors actually see them, it checks more than one page of your site, and it tells you plainly what it could not check, so you never mistake "not tested" for "no problems". Every problem in the report comes with what it means for your visitors and how to fix it, written for the people who look after websites, not only for accessibility specialists. ## 2. The laws: what they ask of your website Accessibility law is different in every country, but for websites the laws below all come back to the same yardstick: WCAG at Level AA. The version each one names is listed so you can see exactly where your site needs to be. This is a plain-English summary, not legal advice; if you are unsure whether a law applies to you, ask a lawyer who works in this area. ### United Kingdom: the Equality Act 2010 The Equality Act 2010 applies to anyone who provides goods, services or facilities to the public in Great Britain, including through a website or app. It requires service providers to make reasonable adjustments so that disabled people are not put at a substantial disadvantage. The Act does not name a technical standard, but WCAG is the standard that UK government guidance, regulators and accessibility specialists use to judge whether a website is accessible. ### United Kingdom: the public sector accessibility regulations The Public Sector Bodies (Websites and Mobile Applications) (No. 2) Accessibility Regulations 2018 apply to central and local government, the NHS, schools, universities and many other public bodies. GOV.UK guidance says public sector websites must "meet the international WCAG 2.2 AA accessibility standard" and publish an accessibility statement explaining any parts that do not. ### European Union: the European Accessibility Act The European Accessibility Act has applied since 28 June 2025. It covers a wide range of products and services sold to consumers in the EU, including online shops, banking services, e-books, and passenger transport booking and information. A business based outside the EU, including in the UK, can still fall under it if it sells these services to people in EU countries. Microenterprises providing services (fewer than 10 staff and an annual turnover or balance sheet of no more than €2 million) are exempt from the service requirements. The Act itself describes accessibility in general terms. The technical detail comes from the European standard EN 301 549. Its latest version, EN 301 549 v4.1.1, was published on 2 September 2026 and uses WCAG 2.2 Level AA as its baseline for websites. It becomes the standard that gives a legal presumption of conformity once it is cited in the Official Journal of the EU, which is expected later in 2026. Until then the earlier version, based on WCAG 2.1 AA, is the cited standard. Checking against WCAG 2.2 AA covers both. ### European Union: public sector websites The EU Web Accessibility Directive has required public sector websites and apps in EU countries to meet EN 301 549, and so WCAG, since 2018 to 2021 depending on the type of site. ### United States: the Americans with Disabilities Act (ADA) In April 2024 the US Department of Justice published a rule under Title II of the ADA requiring the websites and mobile apps of state and local governments to meet WCAG 2.1 Level AA. After an extension published in April 2026, the deadlines are 26 April 2027 for public bodies serving 50,000 people or more, and 26 April 2028 for smaller ones and special district governments. Title III of the ADA covers businesses open to the public. No regulation names a WCAG version for them, but many lawsuits are brought every year over inaccessible business websites, and WCAG Level AA is the yardstick these cases and the settlements that end them refer to. ### United States: Section 508 Section 508 of the Rehabilitation Act applies to US federal agencies and the technology they buy. Its standards incorporate WCAG 2.0 Level AA by reference for web content. Suppliers selling to federal agencies are often asked to show how their websites and products meet it. ### Canada: the Accessibility for Ontarians with Disabilities Act (AODA) In Ontario, the AODA requires public sector organisations and private and non-profit organisations with 50 or more employees to make their websites meet WCAG 2.0 Level AA, apart from two criteria about live captions and audio description. ### What this means for you WCAG 2.2 includes every Level A and AA success criterion from WCAG 2.1 and 2.0, apart from one, 4.1.1 Parsing, which WCAG 2.2 removed because modern browsers and assistive technology no longer depend on it. So a site that meets WCAG 2.2 Level AA meets the level every law above points to. That is why this audit checks against WCAG 2.2 Level A and AA. ## 3. WCAG 2.2 in plain English WCAG stands for Web Content Accessibility Guidelines. It is published by the World Wide Web Consortium (W3C), the international body that develops standards for the web. WCAG 2.2 became a W3C Recommendation in October 2023 and is the current version. ### The four principles Every part of WCAG sits under one of four principles. Content must be: - Perceivable: people must be able to take in the information, whether they see it, hear it or read it with a screen reader or a braille display. Images need text descriptions, videos need captions, and text needs enough contrast to read. - Operable: people must be able to use every part of the page, whether they use a mouse, a keyboard, a switch, voice control or a touchscreen, and they must have enough time and never be put at risk by flashing content. - Understandable: the page must behave in ways people expect, its language must be identified, and forms must say what they need and what went wrong. - Robust: the page must be built so that browsers and assistive technology, such as screen readers, can work out what each part is and what it does. ### Success criteria and levels Under the principles are guidelines, and under the guidelines are success criteria: specific, testable statements such as "text has a contrast ratio of at least 4.5:1". Each success criterion has a number, such as 1.4.3, and a level: - Level A covers the most basic barriers. Without these, some people cannot use the page at all. - Level AA covers the barriers that make a site hard or tiring to use for many people. This is the level the laws in section 2 point to, and it includes everything in Level A. - Level AAA is the highest level. W3C does not recommend requiring it for whole sites, because some content cannot meet every AAA criterion. WCAG 2.2 has 55 success criteria at Levels A and AA. This audit reports on all 55, so you can see where your site stands on each one. ### What WCAG 2.2 added WCAG 2.2 added six success criteria at Levels A and AA: - 2.4.11 Focus Not Obscured (Minimum), AA: when a link, button or field takes keyboard focus, it must not be completely hidden by something else on the page, such as a sticky header, a chat button or a cookie banner. - 2.5.7 Dragging Movements, AA: anything that needs dragging, such as a slider or a drag-and-drop list, must also work with a single tap or click. - 2.5.8 Target Size (Minimum), AA: buttons and links must be at least 24 by 24 CSS pixels, or have enough space around them, so people with limited hand control can hit them. - 3.2.6 Consistent Help, A: if a site offers help, such as contact details, a help page or a chat, it must be in the same place on every page that has it. - 3.3.7 Redundant Entry, A: people must not be asked to type the same information twice in one process, unless it is needed for security or the earlier answer is no longer valid. - 3.3.8 Accessible Authentication (Minimum), AA: signing in must not depend on a memory or puzzle test, such as remembering a password with no way to paste it or use a password manager, unless an alternative is offered. WCAG 2.2 also removed 4.1.1 Parsing, which dealt with errors in page code that modern browsers and assistive technology now handle on their own. ### Conforming to WCAG Under WCAG, a web page conforms at Level AA only when it meets every Level A and AA success criterion. One failure on one criterion means the page does not conform. That is why it matters to know which criteria have been tested, which have failed, and which still need a person to check, rather than looking at a single score. ## 4. What the audit checks, criterion by criterion This audit tests 35 of the 55 WCAG 2.2 Level A and AA success criteria, fully or in part. For each one below you will find what it means for the people using your site, what a failure looks like, and the usual fix. Where a criterion is only partly testable by an automated audit, the report says so and tells you what a person should still check. ### Perceivable: can people take in the content? ### 1.1.1 Non-text Content (A) Blind and partially sighted people who use screen readers hear a text description of each image instead of seeing it. If an image has no description, they hear nothing, or worse, a long file name. The audit checks that every image has a text alternative, that decorative images are correctly marked so screen readers skip them, that file names are not used as descriptions, and that icons drawn as SVG graphics are either named or hidden. The fix is a short alt text that says what the image shows or does, and an empty alt text for images that are only decoration. ### 1.2.2 Captions (Prerecorded) (A) Deaf and hard-of-hearing visitors rely on captions to follow any video with speech or meaningful sound. The audit reports videos that have no captions track. The fix is to add captions, ideally written or checked by a person, as a WebVTT file linked from the video. Whether the captions are accurate needs a person to judge. ### 1.3.1 Info and Relationships (A) Sighted visitors see that a line of large bold text is a heading, that a set of items is a list, and that a label sits next to its field. Screen reader users only get that structure if it is in the page code. The audit checks headings, lists, data tables, form labels, landmark regions such as the main content and navigation, and whether bold or italic tags are used where emphasis should be marked. The fix is to use real headings, lists, table headers and labels rather than text that only looks like them. ### 1.3.4 Orientation (AA) Some people have a tablet or phone fixed to a wheelchair or a stand, and cannot turn it. If a page only works in portrait or only in landscape, they are locked out. The audit checks that the page works in both orientations. The fix is to remove any code or styling that forces one orientation. ### 1.3.5 Identify Input Purpose (AA) People with memory, motor or reading difficulties benefit when the browser can fill in their name, email address, phone number and address for them. That only works if each field says what it collects. The audit reports personal details fields without the matching autocomplete value. The fix is to add autocomplete values such as "email", "tel", "given-name" or "postal-code". ### 1.4.1 Use of Color (A) About one in twelve men and one in two hundred women have red-green colour vision deficiency, the most common kind. If links inside a paragraph are shown only by a different colour, many of them cannot tell where the links are. The audit checks links within blocks of text for this. The fix is to underline links in text, or make sure the colour difference is strong enough and there is another clear sign, such as underlining on hover and focus. ### 1.4.2 Audio Control (A) Sound that starts on its own talks over a screen reader, so blind visitors cannot hear the page. The audit reports audio and video that play sound automatically. The fix is to never play sound automatically, or to give a clear control at the top of the page to stop it. ### 1.4.3 Contrast (Minimum) (AA) Low contrast text, such as pale grey on white, is hard or impossible to read for people with low vision, older visitors, and anyone looking at a phone in sunlight. WCAG asks for a contrast ratio of at least 4.5:1 for normal text and 3:1 for large text. The audit lists any text on your page that falls short, with the colours involved. Text over photos or gradients cannot be measured reliably by any automated check, so the report lists it for a person to look at. The fix is to darken the text or lighten the background until it reaches the ratio. ### 1.4.4 Resize Text (AA) Many people with low vision zoom their browser to read comfortably. At 200% zoom, text must still be readable and nothing should be cut off or overlap. The audit checks the page at 200% zoom and reports text that no longer fits. The fix is to avoid fixed heights on text boxes and let content grow. ### 1.4.10 Reflow (AA) On a phone, or on a desktop browser zoomed to 400%, the page is only 320 CSS pixels wide. If content is wider than that, visitors have to scroll sideways to read every line, which is exhausting and easy to get lost in. The audit checks the page at 320 pixels wide and lists the parts that make it scroll sideways. Data tables, maps and diagrams are allowed to scroll inside their own box. The fix is flexible widths, wrapping rows and a layout for narrow screens. ### 1.4.11 Non-text Contrast (AA) People with low vision need to see where a button or form field is, and where keyboard focus is. WCAG asks for a contrast ratio of at least 3:1 for the edges of controls that identify them, such as the border of a text field, and for focus indicators. The audit measures the edges of buttons and fields and the outlines shown on focus, and lists those that are too faint, with the colours involved. The fix is a darker border or fill, and a strong focus outline. ### 1.4.12 Text Spacing (AA) Many people with dyslexia or low vision widen the spacing between lines, letters, words and paragraphs to make text easier to read, using a browser extension or their own style settings. WCAG sets the spacing a page must cope with. The audit reports text that gets cut off or overlaps at that spacing. The fix is to avoid fixed heights and hidden overflow on boxes that hold text. ### 1.4.13 Content on Hover or Focus (AA) Tooltips and menus that appear on hover can cover what someone is reading, or vanish before a person with a magnifier or a tremor can reach them. WCAG asks that such content can be dismissed without moving the pointer, can be hovered over itself, and stays until the person moves away. The audit checks pop-up content shown on hover for this. The fix is to let Escape close it and keep it open while the pointer is over it. ### Operable: can people use every part of the page? ### 2.1.1 Keyboard (A) Many people cannot use a mouse: blind people, people with tremors or paralysis, and people who use switches or voice control, which act like a keyboard. Everything on the page must work from a keyboard. The audit reports clickable items that cannot be reached with the keyboard, such as links with no address, and scrolling areas the keyboard cannot reach. The fix is to use real links and buttons, which work with the keyboard automatically. Whether every function works by keyboard alone needs a person to try. ### 2.1.2 No Keyboard Trap (A) A keyboard trap is a part of the page that keyboard focus can go into but not leave, such as a badly built pop-up or embedded widget. A keyboard user who gets trapped cannot use the rest of the page at all, and often has to close the browser. The audit reports where keyboard focus gets stuck. The fix is to make sure Tab and Shift+Tab always move on, and that Escape or a close button releases any dialog that keeps focus inside it on purpose. ### 2.2.1 Timing Adjustable (A) Some people need more time to read or complete a task. A page that refreshes or redirects itself on a timer can take them away before they are ready. The audit reports pages set to refresh or redirect automatically. The fix is to remove the timer, or let people turn it off or extend it. Time limits set by scripts, such as session timeouts, need a person to check. ### 2.2.2 Pause, Stop, Hide (A) Moving content, such as carousels, scrolling news tickers and animations, distracts people with attention difficulties and makes reading impossible for some. Anything that moves for more than five seconds must have a way to pause, stop or hide it. The audit reports moving content near the top of the page without a pause control. The fix is a visible pause button, or no automatic movement. ### 2.3.1 Three Flashes or Below Threshold (A) Content that flashes more than three times in one second can cause seizures in people with photosensitive epilepsy. This is one of the few accessibility failures that can cause physical harm. The audit reports flashing above the safe limit. The fix is to remove the flashing or slow it down. ### 2.4.1 Bypass Blocks (A) Keyboard and screen reader users would otherwise have to go through the whole menu on every page before reaching the content. The audit checks for a skip link and for landmark regions such as the main content area. The fix is a "Skip to main content" link as the first item on the page, and a main landmark. ### 2.4.2 Page Titled (A) The page title is the first thing a screen reader announces and the name shown in browser tabs. The audit checks that each page has a title. The fix is a title that says what the page is and which site it belongs to. Whether the title describes the page well needs a person to judge. ### 2.4.3 Focus Order (A) When people move through a page with the Tab key, the order should follow the page in a way that makes sense. Forcing an order with positive tabindex values usually breaks this. The audit reports elements that force their own place in the tab order. The fix is to remove positive tabindex values and let the order follow the page. Whether the order makes sense overall needs a person to check. ### 2.4.4 Link Purpose (In Context) (A) Screen reader users often bring up a list of all the links on a page. Links that say only "click here", "read more" or nothing at all are meaningless in that list. The audit reports empty links and links with vague text. The fix is link text that says where the link goes, such as "Read our pricing guide". ### 2.4.5 Multiple Ways (AA) People find pages in different ways. Some use the menu, some search, and some use a site map. WCAG asks for more than one way to find a page within a site. The audit checks for a site search or a site map. The fix is to add a search box or a site map page. ### 2.4.6 Headings and Labels (AA) Headings and labels help everyone find their way, and screen reader users jump between headings to skim a page. The audit reports empty headings and controls without names. Whether each heading and label describes its content well needs a person to judge. ### 2.4.7 Focus Visible (AA) Keyboard users need to see which link, button or field they are on, just as mouse users see the pointer. Without a visible focus indicator, they lose their place after every key press. Many sites remove the browser's focus outline for design reasons and put nothing in its place. The audit reports controls that show no visible change when they take keyboard focus. It also reports controls that are given a focus outline that a surrounding box then hides, and names the box. The fix is a clear focus style, such as a solid outline, that nothing cuts off. ### 2.4.11 Focus Not Obscured (Minimum) (AA) Sticky headers, cookie banners and chat buttons stay on screen while the page scrolls. When keyboard focus moves to a link underneath one of them, the keyboard user cannot see it. The audit reports controls that are completely hidden behind fixed or sticky content when they take focus, and names what is covering them. The fix is to leave space for sticky content when the page scrolls to the focused item, or to make banners dismissible. ### 2.5.3 Label in Name (A) People who use voice control say what they see: "click Send message". If the button's hidden name is different from its visible label, voice control does not find it, and screen reader users hear something different from what is on screen. The audit checks that the names given to controls contain their visible text. The fix is to make the accessible name start with the visible label. ### 2.5.8 Target Size (Minimum) (AA) Small buttons and links placed close together are hard to tap for people with tremors, arthritis or large fingers, and for anyone on a phone. WCAG asks for targets of at least 24 by 24 CSS pixels, or enough space around them. The audit reports targets that are too small and too close to others. The fix is larger buttons or more space between them. ### Understandable: does the page behave as people expect? ### 3.1.1 Language of Page (A) Screen readers need to know which language a page is in to pronounce it correctly. Without it, an English page may be read out with French pronunciation. The audit checks that the page declares a valid language. The fix is a lang attribute on the page, such as lang="en-GB". ### 3.1.2 Language of Parts (AA) When part of a page is in another language, it should be marked so it is pronounced correctly. The audit checks that any language marked on part of a page is valid. Whether every passage in another language is marked needs a person to check. ### 3.2.1 On Focus (A) Moving through a page with the Tab key must never, by itself, open a new page or window. Keyboard users who are suddenly taken somewhere else lose their place and may not know what happened. The audit reports when pressing Tab opens a new page or window. The fix is to only change page when someone activates a link or button. ### 3.2.3 Consistent Navigation (AA) People who rely on memory, routine or a screen reader learn where things are. If the menu changes order from page to page, they have to learn it again each time. The audit compares the menu on your home page with the same menu on two other pages of your site and reports any change of order. The fix is to keep repeated menus in the same order everywhere. ### 3.2.6 Consistent Help (A) When someone is struggling, they need to find help quickly. If contact details, a help page or a chat appear on several pages, they must be in the same place on each. The audit compares where help appears on your home page and two other pages and reports any change. The fix is to keep help links in the same place, such as the header or footer, on every page. ### 3.3.2 Labels or Instructions (A) Every form field needs a label that stays visible. Placeholder text inside a field disappears as soon as someone starts typing, leaving people with memory difficulties unsure what the field was for. The audit reports fields with no label and fields named only by placeholder text. The fix is a visible label for each field. ### Robust: can assistive technology understand the page? ### 4.1.2 Name, Role, Value (A) Screen readers and voice control need to know what every control is (a button, a checkbox, a menu), what it is called, and what state it is in (ticked, expanded, selected). Custom controls built from plain boxes often give none of this. The audit checks that buttons, links, frames and form controls have names, that ARIA attributes and roles are valid and allowed where they are used, and that nothing a keyboard user can reach is hidden from screen readers. The fix is to use real HTML controls where possible, and correct ARIA where custom controls are needed. ## 5. What makes this audit different It audits your page as your visitors see it. Most modern websites are built or finished by scripts after the page first loads: menus, product lists, cookie banners, chat buttons and whole sections can appear only then. An audit of the page before its scripts run can miss most of what visitors actually meet, or report problems that are fixed once the page has loaded. This audit checks the finished page, after its scripts have run, as your visitors see it. It checks what people actually struggle with. Alongside the full axe-core rule set, it tests keyboard access, focus that can be seen and is not hidden, keyboard traps, reflow on phones, zoom, text spacing, contrast of text and of control edges, flashing, moving content, and consistency across pages. These are among the problems that most often stop people using a site. It checks more than one page. Problems are not always on the home page. The audit also checks two more pages of your site, lists any problems found only there with the page they are on, and compares the pages to check that the menu and help stay consistent. It never assumes a pass. Every one of the 55 WCAG 2.2 Level A and AA success criteria is shown with one of five results: failed, warning, no problems found, needs a person to check, or not checked this time. If something could not be tested on your page, the report says so instead of leaving it out. You always know exactly what was and was not tested. It tells you what to do. Every problem says what it means for your visitors, gives examples from your own page, and explains how to fix it in plain English. It is honest about its limits. No automated audit can prove a website conforms to WCAG, and this one does not claim to. Section 6 explains what still needs a person. ## 6. What no automated audit can do Some WCAG success criteria depend on meaning, purpose or judgement that software cannot reliably assess. A tool can find an image with no description, but it cannot tell whether a description that exists actually describes the image. It can find a video with no captions, but it cannot tell whether the captions say what is spoken. That is true of every automated accessibility tool, not only this one. Of the 55 WCAG 2.2 Level A and AA success criteria, 20 need a person to check in full, and the report marks each of them "needs a person to check" so they are never mistaken for a pass: - Audio and video: audio-only and video-only content (1.2.1), audio description or a media alternative (1.2.3), live captions (1.2.4), and audio description for recorded video (1.2.5). - Meaning and reading order: whether content still makes sense when read in code order (1.3.2), whether instructions rely only on shape, size, position or sound, such as "press the round button on the right" (1.3.3), and whether text is shown as an image when it could be real text (1.4.5). - Keyboard shortcuts and pointer use: single-key shortcuts that can be turned off or changed (2.1.4), gestures such as pinch or swipe having a simple alternative (2.5.1), actions completing on release rather than press so mistakes can be cancelled (2.5.2), features worked by shaking or tilting the device having an alternative (2.5.4), and dragging having a single-tap alternative (2.5.7). - Behaviour and consistency: changing a form setting not causing an unexpected change of page (3.2.2), and items that do the same thing having the same name throughout the site (3.2.4). - Forms and sign-in: errors being identified in text (3.3.1), suggestions for fixing errors being given (3.3.3), legal, financial and data submissions being reversible, checked or confirmed (3.3.4), information not having to be entered twice (3.3.7), and sign-in not depending on a memory or puzzle test (3.3.8). - Status messages: messages such as "Added to basket" or "3 results found" being announced to screen reader users without moving focus (4.1.3). For the 35 criteria the audit does test, some are only partly testable. For those, the report also says what a person should still check, for example whether alt text describes each image well, or whether every function works by keyboard alone. The quickest way to cover what is left is to try your key journeys yourself using only a keyboard, then with a screen reader such as NVDA on Windows or VoiceOver on Mac and iPhone, and to ask disabled people to try your site. An automated audit tells you where to look first; people tell you whether it works. ## 7. How to read your report Errors: must fix. These are failures of a WCAG success criterion, or problems that clearly stop some people using the page. Each one names the criterion, explains who is affected, shows examples from your page, and gives the fix. Start here. Warnings. These are problems that make the page harder to use, or things that are likely to be failures but need a quick look to confirm, such as a form field named only by placeholder text, or links that open a new tab without saying so. Some warnings relate to Level AAA, which goes beyond what the laws ask for but is good practice. Passed. Checks that found no problems on your page. A pass means the audit looked and found nothing wrong for that check; it does not mean every part of that WCAG criterion has been confirmed, because some need a person too. Notes. Notes tell you how the page was audited and anything that limits the results, such as text over images that needs checking by eye, or a check that could not run on this page and why. Problems found on other pages. Problems found only on the other pages checked are listed with the page they are on, for example "(on /contact/)", so you know where to look. The WCAG 2.2 coverage line. At the end of the report, every Level A and AA success criterion is counted under one of five results: - Failed: at least one error was found for this criterion. - With warnings: no errors, but at least one warning. - No problems found: the audit tested this criterion and found nothing wrong. Where the test is partial, a person should still check the rest. - Need a person to check: no automated audit can test this criterion; see section 6. - Not checked this time: the audit can test this criterion, but could not on this run, for example because the site blocked part of the check or has no other pages to compare. Run the audit again later, or check it yourself. The score. The score out of 100 gives a quick sense of how much there is to fix. It goes down with every error and warning, and errors count three times as much as warnings. Use it to track progress over time, not as a measure of compliance: a page with a single error does not conform to WCAG, whatever its score. ## 8. Frequently asked questions ### Does a high score mean my site is compliant? No. Under WCAG, a page conforms at Level AA only when it meets every Level A and AA success criterion, and 20 of those need a person to check. A high score means the audit found few problems in what it could test. It is a strong sign you are on the right track, not proof of compliance. ### Can I say my site is "WCAG compliant" after running this audit? Not on the strength of any automated audit alone, ours or anyone else's. To claim conformance you need to meet every criterion, which means fixing what the audit finds and having a person check the criteria it cannot test. Public sector bodies in the UK must publish an accessibility statement that says honestly which parts of the site do not yet meet the standard. ### Why does the audit check other pages of my site? Two reasons. Problems are not always on the home page, so checking more pages finds more of them. And two WCAG criteria, Consistent Navigation (3.2.3) and Consistent Help (3.2.6), can only be checked by comparing pages. If your site has no other pages to compare, the report marks those two as not checked. ### Why does the report say a check was "not checked this time"? Usually because the site blocked part of the audit, a page took too long to load, or there was nothing to compare. The note in your report says which. Try again later, and if a site blocks automated visits, check those criteria by hand. ### Why might results change between runs? Many sites change from one visit to the next: different products, news stories, adverts or banners appear. The audit checks the page as it is at that moment, so a run on a busy news site may find slightly different problems each time. ### Do I need to fix the warnings? Fix the errors first. Then look at the warnings: many are quick to fix and make a real difference to visitors, and some point to likely failures that need a quick look to confirm. ### How often should I check my site? After any change to your design, templates, menus or forms, and before launching a new site or section. For a site that changes often, a regular check, such as monthly, catches problems before visitors meet them. ### What about accessibility overlays and widgets? Overlays are scripts that add an accessibility menu to a site. They do not change the underlying page code, and they do not make a site meet WCAG on their own. Fixing the problems in the page itself is what makes the difference for visitors. ### Does this audit check PDFs and other documents? No. It checks web pages. PDFs, Word documents and other files linked from your site need checking separately, and the laws in section 2 usually cover them too.