accessibility-pass

---
name: accessibility-pass
description: Tests a UK hospitality website against named WCAG 2.2 success criteria and against the Equality Act duty that already applies to you, produces one row per failure with the criterion number, the page, the element and what a customer cannot do, ranks the failures by who is shut out rather than by how hard they are to fix, and writes the plain English statement you publish. Use before a redesign, when someone tells you your site is not accessible, or when you want to know what is actually wrong rather than a score out of a hundred.
---

# A site everyone can use, and the duty you already have

You give this your website, a browser, a keyboard and about two hours. You get back a numbered list of what a disabled customer cannot do on your site, each item naming the page, the element, the WCAG 2.2 success criterion by number and level, and the customer who is blocked. Underneath it, the same list ranked by who is shut out. Then a plain English accessibility statement you can publish, saying what works, what does not, and when you will fix it. It does not give you a score, and it does not tell you that you comply, because no automatic tool and no document can say that.

## What it does

1. **Settle which rule applies to you first, because the one most often quoted at hospitality owners does not.** The Public Sector Bodies (Websites and Mobile Applications) (No. 2) Accessibility Regulations 2018 are the source of most website accessibility advice online, and GOV.UK's guidance on them says plainly that "All public sector bodies have to meet the requirements, unless they are exempt." A restaurant, a bar, a hotel or a café is not a public sector body, so those regulations do not bind it and nobody is going to audit you against them. What does apply is the Equality Act 2010. Section 20(3) sets the first requirement: where "a provision, criterion or practice" puts a disabled person "at a substantial disadvantage", the duty is "to take such steps as it is reasonable to have to take to avoid the disadvantage". Write both facts at the top of the report so nobody spends a week on the wrong obligation.

2. **Name the standard you are measuring against, with its version and date, and use it consistently.** Use the Web Content Accessibility Guidelines 2.2 at Level AA. WCAG 2.2 became a W3C Recommendation on 12 December 2024, and it is the version GOV.UK's own guidance names for public bodies, which makes it the defensible benchmark for everyone else even though no statute imposes it on a private venue. Every finding in the report cites a criterion by number and level, such as 1.4.3 Contrast (Minimum), Level AA. A finding without a criterion number is an opinion, and an opinion is what a developer argues with. A criterion number is what a developer fixes.

3. **Run an automatic scan on every template, then write down what the scan cannot see, because that is the larger half.** Use a recognised engine rather than a marketing widget that promises a score. The axe-core project states it plainly in its own documentation: "With axe-core, you can find on average 57% of WCAG issues automatically. Additionally, axe-core will return elements as 'incomplete' where axe-core could not be certain, and manual review is needed." Treat the scan as a first pass that finds missing alternative text, unlabelled form fields and contrast failures cheaply, and treat the remaining findings as the part that requires a human. Record which pages were scanned, which engine, and the date. An overlay or widget that claims to fix accessibility is not a scan and does not go in the report.

4. **Tab through every page with the mouse pushed out of reach, and record the first place you get stuck.** Start at the top of the page and press Tab repeatedly. You are looking for three things. Can you reach every link, button, form field and menu. Can you see where you are at each step, which is success criterion 2.4.7 Focus Visible at Level AA, requiring that "Any keyboard operable user interface has a mode of operation where the keyboard focus indicator is visible". And can you get back out of anything you tab into, particularly a cookie banner, a booking widget or a newsletter pop-up. A keyboard trap in a booking iframe is the single most expensive fault a venue site can have, because the customer was trying to give you money.

5. **Check every image for a text alternative, and find the menu, because in hospitality the menu is usually the failure.** Success criterion 1.1.1 Non-text Content, Level A, requires that "All non-text content that is presented to the user has a text alternative that serves the equivalent purpose". A photograph of the dining room needs a short description. A decorative flourish needs an empty alternative so a screen reader skips it. And a menu published as a photograph or a PDF of a photograph has no text at all, which means a blind customer cannot read what you serve, a customer with a severe allergy cannot check ingredients, and a phone on a weak signal shows nothing. Record every image-only menu as a separate finding with the page and the file.

6. **Measure contrast on real text against its real background, not on the brand palette in the abstract.** Success criterion 1.4.3 Contrast (Minimum), Level AA, requires that text and images of text have "a contrast ratio of at least 4.5:1", with large-scale text allowed "a contrast ratio of at least 3:1", large scale being defined as "at least 18 point or 14 point bold". The places this fails in hospitality are predictable: white text laid over a photograph of the bar, pale grey body copy chosen because it looked elegant, and a gold or copper brand colour used for links. Sample text over the lightest and the darkest part of any photographic background separately, because one measurement of a photograph is not a measurement.

7. **Zoom to 200 percent and then squeeze the window to a narrow column, and see what falls off.** Two criteria cover this and they catch different faults. 1.4.4 Resize Text, Level AA, requires that "text can be resized without assistive technology up to 200 percent without loss of content or functionality". 1.4.10 Reflow, Level AA, requires content to be presentable "without requiring scrolling in two dimensions" at "a width equivalent to 320 CSS pixels", with an exception for content that genuinely needs a two dimensional layout. Watch for text that overlaps, buttons that slide off the edge, a fixed header that eats the whole screen, and a price list that turns into a sideways scroll. Record the width or zoom level at which each one breaks.

8. **Work the forms and the booking flow, because that is where a failure costs a booking rather than a compliment.** Success criterion 3.3.2 Labels or Instructions, Level A, is one sentence: "Labels or instructions are provided when content requires user input." A field whose only label is grey placeholder text that vanishes when you type fails it. Then check the controls themselves against 2.5.8 Target Size (Minimum), Level AA, which is new in WCAG 2.2 and requires that "The size of the target for pointer inputs is at least 24 by 24 CSS pixels" subject to a spacing exception. Then check 2.5.7 Dragging Movements, Level AA, which requires that dragging functionality "can be achieved by a single pointer without dragging" unless dragging is essential. Date range sliders and drag-to-select calendars are the usual offenders.

9. **Rank the findings by who is shut out, write the statement, and put a review date on it.** Not by severity in the abstract and not by how cheap the fix is. Three groups: a customer cannot complete a booking or read the menu at all; a customer can complete it but with substantial difficulty; a customer is inconvenienced. Then write the statement in plain words: what works, what does not, what you are fixing and by when, and a phone number and email for anyone who hits a problem, staffed by a named person. The Equality Act 2010 Code of Practice for services, published 5 August 2026, records that service providers should "review regularly whether services are accessible to disabled people", so the statement carries a review date, not just a publication date.

## Then it checks

1. The report states which regulations apply to this business and which do not, with the Public Sector Bodies Accessibility Regulations explicitly named as not applying and the Equality Act duty named as the one that does.
2. Every finding cites a WCAG 2.2 success criterion by number and conformance level, names the page URL and the specific element, and describes what a customer cannot do, with no finding recorded as a general observation.
3. The automatic scan results and the manual findings are held in separate lists, the scanning engine and date are named, and no accessibility overlay or widget appears anywhere in the evidence.
4. Every page in the sample was tabbed through end to end by a named person on a named date, and each keyboard trap is recorded with the element it traps in and whether escape was possible.
5. Every contrast failure records the measured ratio, the foreground and background colours sampled, and for photographic backgrounds at least two samples from different parts of the image.
6. The published statement names what is broken as well as what works, carries a named contact with a phone number and an email, and carries a review date in the future rather than only a publication date.

Any check fails: name it, redo that step once. Failed twice: say what is wrong and stop.

## Rules
- Public information only.
- Never invent a fact, a number or a quote.
- Anything sent in someone's name says whose name it is. An accessibility statement published under the owner's name goes to the owner first.
- Never state that the site is accessible, compliant, or conforms to WCAG at any level. Conformance is a claim about every page and every state of every page, an audit is a sample, and an owner who publishes a conformance claim they cannot support has created a written misstatement where before they only had a broken menu.
- Never recommend an accessibility overlay, toolbar or widget that claims to fix a site with one line of script. It does not remove the failures it covers, it adds a layer between the customer and the page, and it is refused here whatever the vendor's own claims say.
- Never produce a percentage score, a grade or a number out of a hundred. A score lets an owner stop at 80 while the menu is still a photograph, and it hides which customer is actually excluded.
- Never close a finding because a developer says it is fixed. Re-run the same test, on the same page, with the same method, and record the date it passed.
- Never use the words accessible or step free as a summary of the venue itself. This skill covers the website; the building is a separate job with separate facts, and running them together lets a fixed website imply a fixed front door.
- This output is a working document prepared for the owner to check and for a suitably qualified accessibility auditor or their solicitor to review before any statement is published. It applies published success criteria to a sample of pages on one date. It is not an audit certificate, it is not legal advice, and it does not certify conformance with WCAG or compliance with the Equality Act.

## Built from
- Equality Act 2010, section 20, https://www.legislation.gov.uk/ukpga/2010/15/section/20, read 16 September 2026: the first requirement in subsection (3) and the accessible format provision in subsection (6), which is the duty step 1 names as the one that actually applies to a private venue.
- W3C, "Web Content Accessibility Guidelines (WCAG) 2.2", W3C Recommendation 12 December 2024, https://www.w3.org/TR/WCAG22/, read 16 September 2026: the standard named in step 2, and the success criteria quoted in steps 4 to 8, each also read on its own Understanding page at https://www.w3.org/WAI/WCAG22/Understanding/.
- GOV.UK, "Understanding accessibility requirements for public sector bodies", https://www.gov.uk/guidance/accessibility-requirements-for-public-sector-websites-and-apps, last updated 30 September 2024, read 16 September 2026: the scope statement in step 1 that establishes these regulations do not bind a private hospitality business, and the WCAG 2.2 AA standard they name.
- Equality and Human Rights Commission, "Equality Act 2010: Code of Practice for services, public functions and associations, 2026", published on GOV.UK 5 August 2026, https://www.gov.uk/government/publications/equality-act-2010-code-of-practice-for-services-public-functions-and-associations-2026/equality-act-2010-draft-code-of-practice-for-services-public-functions-and-associations-2026, read 16 September 2026: the statement that the services obligation applies to a website, and the regular review expectation behind the review date in step 9.
- Deque Systems, axe-core, README, https://raw.githubusercontent.com/dequelabs/axe-core/develop/README.md, no publication date shown on the page, read 16 September 2026: the 57 percent figure and the "incomplete" concept in step 3, which is why the scan is a first pass rather than the report.

# accessibility-pass

## You are given
A list of the page URLs to be tested for one UK hospitality website, with the template each page belongs to. The saved HTML and the computed styles for each page. The raw output of an automatic accessibility scan, with the engine name, engine version and scan date supplied. The manual test notes, already carried out by a named person on a named date, arriving as one record per test covering the keyboard walk, the contrast samples, the zoom and reflow observations and the form and booking flow walk. For each manual finding, the WCAG 2.2 success criterion number, its title and its conformance level, all already decided and supplied. The three-band ranking of who is shut out, already decided. The drafted accessibility statement as finished copy. And the retest results where a previous pass recorded findings.

## Produce
Write into a `./accessibility-pass-output/` folder:

1. `findings.csv` with these columns in this order: `finding_ref`, `page_url`, `template`, `element_selector`, `element_text_verbatim`, `criterion_number`, `criterion_title`, `conformance_level`, `detection_method`, `what_the_customer_cannot_do`, `who_is_blocked`, `shut_out_band`, `date_found`, `found_by`, `status`, `date_retested`. `finding_ref` is F001 upward. `detection_method` is exactly one of `automatic scan` or `manual test`. `conformance_level` is exactly `A` or `AA`. `shut_out_band` is exactly one of `cannot complete at all`, `substantial difficulty`, `inconvenienced`. `status` is exactly one of `open`, `fixed and retested`, `claimed fixed not retested`, `will not fix`.
2. `scan-results.csv` with columns: `page_url`, `engine_name`, `engine_version`, `scan_date`, `violations_count`, `incomplete_count`, `passes_count`, `inapplicable_count`, `criterion_number`, `rule_id`, `impact_as_reported`. One row per reported rule result per page. Values are copied from the scan output unchanged.
3. `keyboard-walk.csv` with columns: `page_url`, `tab_stop_order`, `element_selector`, `element_text_verbatim`, `focus_indicator_visible`, `reachable`, `escapable`, `trap_description`, `tested_by`, `date_tested`. The three yes or no columns are `yes`, `no` or `not applicable`. Every row with `escapable` set to `no` also appears in `findings.csv` against criterion 2.4.7 or 2.1.2 as supplied.
4. `contrast-samples.csv` with columns: `page_url`, `element_selector`, `text_sample_verbatim`, `foreground_hex`, `background_hex`, `background_type`, `font_size_points`, `is_bold`, `is_large_scale`, `measured_ratio`, `required_ratio`, `passes`. `background_type` is exactly one of `solid`, `gradient`, `photograph`, `video`. Any row whose `background_type` is `photograph`, `gradient` or `video` must have at least two rows for the same `element_selector` sampled at different points, or the element is listed in `gaps.md`. `required_ratio` is `4.5` or `3` and is set from `is_large_scale`.
5. `reflow-and-zoom.csv` with columns: `page_url`, `test_type`, `width_or_zoom_tested`, `breaks_at`, `symptom`, `content_lost`, `two_dimensional_scroll`, `criterion_number`. `test_type` is exactly `resize text to 200 percent` or `reflow at 320 CSS pixels`. `content_lost` and `two_dimensional_scroll` are `yes` or `no`.
6. `images-and-menus.csv` with columns: `page_url`, `image_src`, `alt_attribute_present`, `alt_text_verbatim`, `is_decorative`, `contains_text`, `text_in_image_verbatim`, `is_menu_or_price_list`, `criterion_number`. `contains_text` and `is_menu_or_price_list` are `yes` or `no`. Every row where `is_menu_or_price_list` is `yes` and `alt_text_verbatim` does not carry the full text of the menu is listed in `gaps.md`.
7. `accessibility-statement.md` containing the supplied statement copy reproduced exactly, with nothing added, removed or reworded, and `ranked-list.md` listing the findings grouped by `shut_out_band` in the supplied order.
8. `gaps.md` is a numbered list of: every finding with no criterion number or no conformance level; every finding with no `what_the_customer_cannot_do` text; every page in the supplied list that was not scanned and not manually tested; every photographic, gradient or video background with fewer than two contrast samples; every image-only menu or price list; every finding whose status is `claimed fixed not retested`; every `will not fix` with no reason recorded; and any statement lacking a named contact, a telephone number, an email address or a future review date.

## Rules
- Codex measures, records and checks. It never decides whether something is a failure, never assigns a success criterion, never writes or reworks the accessibility statement, and never edits the website's HTML or styles.
- Never write the words compliant, conformant, accessible or WCAG conformant as a verdict about the site, a page or the business in any file. Findings are recorded per criterion per element and are never aggregated into a conclusion.
- Never produce a score, a percentage, a grade, a pass mark or a total that could be read as one. No `total_score` column, no summary rating, no traffic light.
- Never record an accessibility overlay, toolbar or widget as a remediation. Where one is found on a page, record it in `gaps.md` as present, with the script source, and nothing more.
- Never mark a finding `fixed and retested` without a `date_retested` and a retest record showing the same page, the same element and the same method. A developer's statement that it is fixed sets `claimed fixed not retested`.
- Never write a benchmark, an industry average, a figure for how many customers have a disability, or a percentage of sites that fail a given criterion. No such figure is to be written into any file.
- Contrast ratios are computed from the supplied hex values, recorded to one decimal place, and never estimated by eye or copied from a design document.
- Use British English, GBP and DD Month YYYY dates. No em dashes in any file you write, and any supplied copy containing one is reproduced verbatim and flagged in `gaps.md`.
- Every file ends with this line: this is a working document prepared for the owner to check and for a suitably qualified accessibility auditor or their solicitor to review before any statement is published. It is not an audit certificate, it is not legal advice, and it does not certify conformance or compliance.

## Return
The absolute path of each file written, the row count of each CSV, the number of findings broken down by `detection_method`, by `conformance_level` and by `shut_out_band`, the criterion numbers that appear most often with their counts, the number of pages in the supplied list that were neither scanned nor manually tested, every keyboard trap with its page and element, the number of contrast samples failing their required ratio and how many of those sit on photographic backgrounds, the number of image-only menus or price lists with the pages they appear on, the count of findings at each status with every `claimed fixed not retested` named, whether any accessibility overlay was found and on which pages, and the `gaps.md` item count.