mobile-check

---
name: mobile-check
description: Runs the five things a customer actually does on your website from a real phone, on a real network, and records what happened, with tap counts, the point of failure and the device it failed on, measured against named WCAG 2.2 success criteria rather than a score. Use when most of your visitors are on phones and nobody has ever opened the site on one, when bookings stop halfway, or before you pay anybody to redesign it.
---

# Find out what your site actually does on a phone

You give this your website, two or three real phones and an hour of somebody's evening. You get back a record of five customer jobs attempted on each phone, each with the number of taps it took, the seconds it took, and the exact point where it broke, plus a list of faults tied to named WCAG 2.2 success criteria, ranked by the job that loses you money. It does not give you a mobile score out of a hundred, and it does not test speed, which is a separate job with separate tools.

## What it does

1. **Test on real phones, on mobile data, not on a desktop browser squeezed narrow.** A narrowed desktop window has a mouse, a full size keyboard, a fast connection and no operating system font scaling, and it will pass tests that a phone fails. Borrow an iPhone and an Android handset, ideally one of each that is three or four years old, turn off wi-fi, and hold them the way a customer holds them, one handed, walking. The GOV.UK Service Manual says the same thing about scope: "Your service must be universally accessible. This means building it to work on every browser or device that your users access it on." Record the exact handset, operating system version, browser and network for every test, because "it works on my phone" is not a finding and two phones can differ on the same site.

2. **Write down the device and browser list you are testing against before you start, and say why.** The GOV.UK Service Manual publishes the combinations that cover the overwhelming majority of its users: on iOS, Chrome, Safari and Edge; on Android, Chrome, Samsung Internet and Firefox; plus the desktop browsers. Samsung Internet is the one venues forget and it is common in the UK. Then add anything specific to your customers, such as an older handset if your regulars are older. The Service Manual also warns against treating this as a decision made once: "Decisions about compatibility cannot be something you specify at the start of your project and then forget about." Put a review date next to the list.

3. **Test the five jobs a customer came to do, not the pages your site happens to have.** Find today's opening hours. Find the address and get walking or driving directions. Read the menu and find one specific dish or price. Phone the venue. Make or request a booking. Each one starts from a cold Google search on the phone, not from your home page, because that is where a real customer starts. For each job record the taps, the seconds, whether it completed, and the screen where it failed. A job that takes eleven taps is a finding even if it completes, and a tap count is the one number in this whole exercise that an owner can argue with nobody about.

4. **Measure the things you press.** Success criterion 2.5.8 Target Size (Minimum), Level AA and new in WCAG 2.2, requires that "The size of the target for pointer inputs is at least 24 by 24 CSS pixels", with an exception where "Undersized targets ... are positioned so that if a 24 CSS pixel diameter circle is centered on the bounding box of each, the circles do not intersect another target". Check the controls that matter: the phone number, the booking button, the menu link, the navigation toggle, the close control on any pop-up. Then check something the criterion does not cover, which is whether they sit where a thumb reaches. A booking button in the top right corner of a large handset requires two hands, and a customer walking to the restaurant has one.

5. **Turn the phone's own font size up and see what survives, then check the narrow width.** Real people change the system font size and then never think about it again. Two criteria cover what should happen. 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 presentable "without requiring scrolling in two dimensions" at "a width equivalent to 320 CSS pixels", excepting content that genuinely needs a two dimensional layout such as maps and data tables. Watch for prices clipped off the right edge, a fixed header that swallows half the screen, buttons overlapping text, and a sideways scroll that hides the second column of the menu.

6. **Work every form field on the phone keyboard, because this is where bookings die.** Tap each field and look at the keyboard that appears: a party size field should raise a number pad, a phone field should raise the telephone pad, an email field should raise the keyboard with the at symbol on it. Then check the labels. Success criterion 3.3.2 Labels or Instructions, Level A, requires simply that "Labels or instructions are provided when content requires user input", and a field labelled only by placeholder text that vanishes as you type fails it, on a phone worse than anywhere because you cannot see the whole form at once. Finally test the date control against 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".

7. **Count the interruptions and see what happens when they arrive together.** On a phone screen a cookie banner, a newsletter pop-up, an app install prompt and a chat bubble can occupy the entire visible area at once, and each of them has a close control smaller than a fingertip. Load the site cold and record every overlay in the order it appears, how much of the screen each covers, whether its close control can be hit reliably, and whether dismissing one reveals another. Then do it again after accepting and after refusing the cookie banner, because the sequence differs. If the phone number or the booking button is covered at any point in that sequence, that is the finding, and it usually outranks everything else in the report.

8. **Open the menu the way a customer will, and if you take orders online, check the allergen information appears twice.** A menu published as a PDF on a phone opens in a separate viewer, arrives as a page of text the width of a sheet of A4, and has to be pinched. Record how many taps it takes to read one price. If the site takes orders for delivery or collection, the Food Standards Agency guidance for food businesses, last updated 17 July 2026, states that for distance selling "allergen information must be provided at two stages in the order process", before the purchase is completed and again when the food is delivered. Check both stages on the phone, because a step that exists on the desktop flow is not evidence it exists on the mobile one.

9. **Write one row per job per device, rank by the job that costs you money, and retest on the same handset.** The report is a grid: five jobs down the side, each phone across the top, with completed or failed, the tap count, the seconds and the failure screen in each cell. Then a ranked list, ordered by money rather than by effort: booking fails, then phone number fails, then menu fails, then directions, then hours. Attach a screenshot of every failure with the handset and the date in the file name. When a fix lands, repeat the same job on the same handset in the same browser and record the new numbers next to the old ones. A fix verified on a desktop is not verified.

## Then it checks

1. Every test record names the handset model, operating system version, browser and browser version, the network type, the tester and the date, with no record attributed to a desktop browser at a narrowed width.
2. All five customer jobs were attempted on every device in the list, each started from a search rather than from the home page, with a tap count, an elapsed time and a completed or failed outcome recorded for each.
3. Every fault cites a WCAG 2.2 success criterion by number and level where one applies, or is recorded explicitly as a usability finding with no criterion, and none is recorded as a general impression.
4. Every measured control records its size in CSS pixels and, where it is under 24 by 24, whether the spacing exception applies, rather than being described as small or fiddly.
5. The overlay sequence was captured three times, cold, after accepting and after refusing, with the proportion of the screen covered and whether the telephone number or booking control was obscured at any point.
6. Every failure has a screenshot naming the handset and the date, and every fix has a retest on the same handset, same browser and same job, with both sets of numbers kept.

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.
- Never report a result from a desktop browser at a narrowed window as a mobile result, and refuse to sign off a fix that has only been checked that way. The device emulator in a desktop browser is useful for reproducing a fault and is not evidence of whether it is fixed.
- Never produce a mobile score, a grade or a percentage. A number lets an owner feel finished while the booking button is still under a pop-up, and it hides which of the five jobs is broken.
- Never state how many of your customers use a phone, how much traffic is mobile, or an industry figure for mobile booking rates. Read your own analytics if you have them and quote your own number with its date, or say you do not know.
- Never test the site on the venue's own wi-fi only. The customer standing outside deciding whether to come in is on a weak mobile signal, and that is the condition that matters.
- Never fix a fault found on one handset without retesting the same job on the others. A change that helps a large iPhone can break a small Android, and the report is the only place that would show up.
- This output is a working document prepared for the owner to check and for whoever maintains the website to act on. It records what specific handsets did on specific dates. It is not an accessibility audit, it is not a performance test, and it does not certify that the site works on devices that were not tested.

## Built from
- Government Digital Service, "Designing for different browsers and devices", GOV.UK Service Manual, https://www.gov.uk/service-manual/technology/designing-for-different-browsers-and-devices, last updated 30 January 2026, read 16 September 2026: the universal accessibility statement and the browser list in steps 1 and 2, and the warning against fixing a compatibility decision once and forgetting it.
- W3C, "Web Content Accessibility Guidelines (WCAG) 2.2", W3C Recommendation 12 December 2024, https://www.w3.org/TR/WCAG22/, read 16 September 2026, with each criterion also read on its Understanding page at https://www.w3.org/WAI/WCAG22/Understanding/: criterion 2.5.8 in step 4, criteria 1.4.4 and 1.4.10 in step 5, and criteria 3.3.2 and 2.5.7 in step 6.
- Food Standards Agency, "Allergen guidance for food businesses", published on GOV.UK 2 April 2020, last updated 17 July 2026, https://www.gov.uk/government/publications/allergen-guidance-for-food-businesses/allergen-guidance-for-food-businesses, read 16 September 2026: the two stage requirement for distance selling in step 8.
- 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, which is why the phone findings in steps 4 to 6 are treated as more than preference.
- GoogleChrome/lighthouse, project readme, https://raw.githubusercontent.com/GoogleChrome/lighthouse/main/readme.md, no publication date shown on the page, read 16 September 2026: the tool the skill recommends for reproducing a fault in a controlled way, and the scoring approach the skill deliberately does not adopt.

# mobile-check

## You are given
The device and browser list for one UK hospitality website, supplied as one row per combination with the handset model, operating system version, browser, browser version and the reason it is in the list. The job attempt records, already carried out by named testers on named dates, arriving as one record per job per device covering the starting search term, every tap in order with what was tapped, the elapsed seconds, the completion outcome and the screen where it failed. The measured control sizes, supplied in CSS pixels with the selector and the page. The overlay sequence observations for each of the three states. The form field observations, one per field, giving the input type, the keyboard raised, the label and how the label behaves when typing. The zoom and reflow observations. The WCAG 2.2 success criterion number, title and conformance level for each fault where one applies, already decided by Claude. The money ranking of the five jobs, already decided. The screenshot file paths. And, where a fix has landed, the retest records in the same format as the original job attempts.

## Produce
Write into a `./mobile-check-output/` folder:

1. `devices.csv` with these columns in this order: `device_ref`, `handset_model`, `os_version`, `browser`, `browser_version`, `screen_width_css_pixels`, `network_type`, `system_font_scale`, `reason_in_list`, `tester`, `date_tested`. `device_ref` is D01 upward. `network_type` is exactly one of `mobile data`, `wifi`, `both tested`. Any row whose `handset_model` names a desktop browser or an emulator is written and immediately listed in `gaps.md`.
2. `job-attempts.csv` with columns: `attempt_ref`, `device_ref`, `job`, `started_from`, `tap_count`, `elapsed_seconds`, `outcome`, `failure_screen`, `failure_description`, `screenshot_path`, `tester`, `date_tested`. `job` is exactly one of `find opening hours`, `find address and directions`, `read menu and find a price`, `telephone the venue`, `make or request a booking`. `started_from` is exactly one of `search engine result`, `home page`, `direct URL`. `outcome` is exactly one of `completed`, `completed with difficulty`, `failed`, `not attempted`.
3. `job-grid.csv` with columns: `job`, then one column per `device_ref` holding `outcome/tap_count/elapsed_seconds`, then `money_rank`. Five rows, one per job, ordered by `money_rank` ascending. `money_rank` is the supplied ranking and is never recalculated.
4. `control-sizes.csv` with columns: `page_url`, `device_ref`, `control_purpose`, `element_selector`, `width_css_pixels`, `height_css_pixels`, `meets_24_by_24`, `spacing_exception_applies`, `nearest_target_distance_css_pixels`, `criterion_number`, `thumb_reachable_one_handed`. `control_purpose` is exactly one of `telephone link`, `booking control`, `menu link`, `navigation toggle`, `overlay close`, `form submit`, `other`. The three yes or no columns are `yes`, `no` or `not assessed`.
5. `overlays.csv` with columns: `device_ref`, `state`, `overlay_order`, `overlay_name`, `screen_proportion_covered`, `close_control_size_css_pixels`, `close_control_reachable`, `obscures_telephone_link`, `obscures_booking_control`, `dismissing_reveals_another`, `screenshot_path`. `state` is exactly one of `cold load`, `after accept all`, `after reject all`. `screen_proportion_covered` is recorded as a percentage to the nearest whole number.
6. `form-fields.csv` with columns: `page_url`, `device_ref`, `field_name`, `input_type_attribute`, `keyboard_raised`, `expected_keyboard`, `keyboard_correct`, `label_present`, `label_method`, `label_persists_when_typing`, `autocomplete_attribute`, `criterion_number`. `label_method` is exactly one of `visible label element`, `placeholder only`, `aria-label`, `adjacent text`, `none`.
7. `reflow-and-zoom.csv` with columns: `device_ref`, `page_url`, `test_type`, `setting_applied`, `symptom`, `content_lost`, `horizontal_scroll_present`, `criterion_number`, `screenshot_path`, and `retests.csv` with columns: `attempt_ref`, `original_tap_count`, `original_elapsed_seconds`, `original_outcome`, `retest_date`, `retest_device_ref`, `retest_tap_count`, `retest_elapsed_seconds`, `retest_outcome`, `same_device_and_browser`. `same_device_and_browser` is `yes` or `no`, and a `no` is listed in `gaps.md`.
8. `gaps.md` is a numbered list of: every job and device combination with outcome `not attempted`; every attempt with `started_from` other than `search engine result`; every device row that names a desktop browser or emulator; every device tested on wifi only; every control under 24 by 24 CSS pixels without the spacing exception assessed; every overlay that obscures the telephone link or the booking control in any state; every form field whose `keyboard_correct` is `no` or whose `label_method` is `placeholder only` or `none`; every fault with no criterion number and no explicit usability label; every failure with no screenshot path; and every retest where `same_device_and_browser` is `no`.

## Rules
- Codex measures, records and checks. It never attempts a job, never decides whether a fault breaches a criterion, never reranks the five jobs, and never edits the website.
- Never record a result taken in a desktop browser at a narrowed width, or in a device emulator, as a device result. Such records are written with the device row flagged and listed in `gaps.md`, and they never appear in `job-grid.csv`.
- Never produce a mobile score, a grade, a percentage pass rate or any single number that summarises the site. No `total_score` column and no summary rating.
- Never write a figure for the proportion of visitors on mobile, an industry mobile conversion rate, or any benchmark. Where the owner supplies their own analytics figure, it is recorded with its source and date and is never compared to an external number.
- Never mark a job `completed` where the tester recorded difficulty. `completed with difficulty` is its own outcome and it carries into the ranked grid unchanged.
- Never treat a fix as verified without a retest row on the same `device_ref` and the same browser version, running the same job from the same starting point.
- Tap counts and elapsed seconds are recorded as counted and timed, never estimated, rounded up to a tidy number, or averaged across devices.
- Use British English, GBP and DD Month YYYY dates. No em dashes in any file you write, and any supplied text 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 whoever maintains the website to act on. It records what specific handsets did on specific dates. It is not an accessibility audit, it is not a performance test, and it does not certify that the site works on untested devices.

## Return
The absolute path of each file written, the row count of each CSV, the number of devices in the list with any that are desktop browsers or emulators named, the number of job attempts broken down by outcome and by job, the five jobs in supplied money rank order with their worst tap count and worst elapsed time across devices, every job and device combination not attempted, the number of controls failing the 24 by 24 test and how many of those have the spacing exception unassessed, every overlay that obscured the telephone link or the booking control with its state and device, the number of form fields raising the wrong keyboard and the number labelled by placeholder only, every failure with no screenshot, the retests recorded and any that ran on a different device or browser from the original, and the `gaps.md` item count.