Inclusify Accessibility

Use this when a site Inclusify already knows about is reachable on ANOTHER hostname the widget also needs to serve on — a country TLD, a subdomain, a staging host. WRITES to this website's Inclusify configuration, never to the site itself: no code, theme or DNS is touched, and adding a hostname here does not make it resolve. For a site Inclusify has never heard of, use add_website instead — this tool only adds to an existing one. The new hostname must be the SAME NAME as the site's existing domains: from "example.com" you may add "example.co.uk" or "shop.example.com", but not "somethingelse.com" — that is refused, and the refusal says what would have been allowed. Localhost and IP addresses are refused. A domain already registered to another Inclusify account is refused and needs support, because a hostname belongs to exactly one account. The first domain on a website becomes its primary; later ones do not. After adding, the widget must still be installed on that hostname — call widget_status to check whether it has reported in.

Use this when a page that matters is not being watched at all — a checkout, an account area, a campaign landing page missing from list_monitored_pages — and should be checked from now on. WRITES to this website's Inclusify configuration — never to the site itself: adds URLs to the set of pages scanned on the daily monitoring rotation. Add-only: it never removes, pauses or edits a page; those stay in the Inclusify panel. Idempotent: a URL already monitored is reported back as alreadyMonitored, not duplicated and not an error. Every URL must be on the website's own domain(s); up to 20 per call. All-or-nothing against the plan's audited-page allowance: if the batch would not fit (paused pages hold their slots too), nothing is added and the response says what would. Loads no page and costs no page allowance. New pages are picked up by the scan worker's continuous queue — never-scanned pages first, then a re-scan roughly every 20h — not instantly; for an immediate answer use start_crawl or a live check tool.

Use this when the user names a site that is not in their Inclusify account yet — list_websites does not have it, or a per-website tool answered that no such website exists. This is also the tool that fills in an account registered without a website at all, which /api/agent/start supports and which is a normal state rather than a half-finished signup. WRITES to the account's Inclusify configuration — never to the site itself: registers a domain as a website in the account, on the free plan, and starts nothing. No scan is run, no widget is installed on the site, nothing is charged and no plan is changed. Takes no "website" argument, because the point is that the website does not exist yet. REQUIRES CONFIRMATION: call it first without "confirm" to get a preview naming the exact domain, show that to the user, and only call again with the token once they have agreed — a domain can be registered to one Inclusify account only, so claiming it takes it from anyone else who might. Idempotent: a domain already in this account comes back as a no-op, not an error and not a second website. Refuses rather than guessing when the account has more than one workspace, because a website lands in exactly one and picking wrong hides it. At most 50 websites per account through this tool; the Inclusify panel has no such limit.

Use this when the customer has decided to upgrade, downgrade or cancel and needs the place to do it: 'how do I upgrade', 'where do I change my plan', 'send me the link', 'how do I cancel'. Use plan_options first if they are still deciding — that one has the prices and what each plan includes; this one is just the door. Returns the correct URL for this website's billing owner, which is not the same for every customer: a Shopify-billed store can only change plan on the Inclusify app's plan page in its own Shopify admin, a Wix-billed site only in its own Wix account (and that link has to be opened in a new tab), an Inclusify-billed website changes it on the website's page in the panel, and an invoice-managed website has no self-serve route at all — for that one this returns no link and says who to contact, rather than sending them somewhere that will not work. IMPORTANT: this returns a URL and does nothing else. It does not create a checkout session, does not charge a card, does not change a plan, and does not start a trial. Nothing on this server can — completing a plan change requires a human, signed in, in their own browser, and that is deliberate rather than a gap. Say so when handing the link over; do not imply the upgrade has been arranged. Works on every plan including Free. Read-only: one indexed read, no page load.

Use this to check one page's images and alt text NOW — including a page no scan has ever covered, and straight after changing images or writing alt text, when the stored scan is already out of date. READ-ONLY: loads one page and inspects it; changes nothing. For what a stored scan already recorded across the site, which is free, use list_alt_findings instead. This one loads a page, so it is metered against the website's daily browser-check allowance and its monthly distinct-page allowance. It checks every image on the page for alt-text problems that can be decided from the markup: a missing alt attribute (which is not the same as an empty one), a filename used as alt, a redundant "image of" opener, alt too long to hear in one breath, alt that merely repeats the visible caption, and an image that is the only content of a link and leaves it with no accessible name. Images correctly marked decorative are counted and deliberately not reported, and neither is the same alt repeated across images: markup cannot tell a product gallery from a row of different products. The decidable version of that — one accessible name, two link destinations — comes from screen_reader_transcript. Whether an existing, plausible-looking alt actually describes its picture is a different question and is not judged here. Findings are capped at 20, worst impact first; imageCount and a stated findingsOmitted count cover the rest on a large gallery or catalogue page. A run that lands on a bot-protection interstitial rather than the page is reported as void, never as clean, and a void run carries no image counts and no findings. Where the interstitial title is contradicted by a page's worth of images, the run stands and carries challengeSuspected instead: trust the images, not the title. Read-only: nothing is written to the site.

Use this in CI or a deployment pipeline when a build should be blocked or allowed based on the site's accessibility: it turns the last recorded scan into a single passed true/false verdict against your thresholds. Criteria: minScore (1-100), maxCritical (critical-severity violations), maxSerious (the high-severity tier, what axe calls serious) — any combination; with none given it defaults to minScore 90 and says so in the response. A failing verdict comes back as a normal result, not an error: read passed, do not retry. A website with no scan on record FAILS the gate — unmeasured must not pass CI — and so does one whose last scan attempt did not finish. The verdict names how many pages the judged scan covered; a pass over 1 page certifies that page, not the site. Judges the record only: no page is loaded, nothing is scanned by calling it. ENTERPRISE plan. Read-only.

Use this when the question is documentary rather than technical: a demand letter, complaint or lawsuit, a procurement or customer accessibility questionnaire, an ADA / EAA / Section 508 conformance claim, 'what evidence do we have', 'what does our accessibility statement actually claim'. The evidence Inclusify holds for one website: the accessibility statement (company name, conformance level claimed, standards named, whether it is published and when, contact details on it) and the scanning record behind it (how many pages are checked against how many the plan includes, when the site was last checked, how many checks are on record, and whether anything is currently blocking them). Also returns an explicit list of gaps in that record. What it adds over site_overview: that tool's "statement" block says only whether one exists and is published, so if the question is 'is our statement live' it has already been answered and this call adds nothing. This one is the contents — the company named, the conformance level claimed, the standards named, and whether there is any contact route for reporting a barrier — plus how many checks are on record behind it and an explicit list of gaps. It holds no per-criterion WCAG status and no scan history; score_history and list_violations own those. This tool cannot and does not say whether a site is legally compliant — nothing in the data supports that conclusion, and it must not be inferred or reported as one. Report what is on record and what is missing, and leave the legal question to the customer's counsel. Read-only: costs one read and loads no page.

Use this when the question is COVERAGE — how much of the site has actually been checked, which pages are the worst — or to collect the outcome of a crawl you queued with start_crawl. Read it before quoting any site-wide number, because it is the tool that says what the rest of them are a sample of. The latest full-site crawl of a website: status, the URL it started from, how many pages it found against how many it actually scanned, the average score, totals by impact, when it ran, and the worst-scoring pages it produced. Read the found-vs-scanned numbers before quoting the average: a crawl audits at most the plan's page allowance, so on a large site the average describes a sample and this tool says so explicitly. Returns the most recent crawl whatever its state, including a failed or still-running one, so the numbers can be partial; the status field says which. Read-only, from stored results — it does not start a crawl, load any page or spend page allowance. A website that has never been crawled says so, which is missing coverage rather than a clean site. For a page's trend over time use page_history; a crawl is one dated snapshot.

Turns what a scan found into issues a developer or a coding agent can work through, one per finding pattern. A pattern is one rule failing on one element shape, across every page it appears on, so a component broken in fifty places is a single issue naming all fifty rather than fifty issues or one unreadable list. Each carries the failing markup, the affected pages and the call that checks a fix before a pull request is opened. WRITES to the customer's GitHub repository, which no other tool on this server does, and never to the site itself. The repository comes from set_github_repo; this will not choose one. REQUIRES CONFIRMATION: the first call returns the exact list it would open and opens none of it. Safe to call twice, because a pattern already tracked is skipped rather than filed again. Refuses entirely if the run would exceed the website's issue cap, instead of filing part of it. Needs the PRO plan.

Use this when keyboard_walk, simulate_condition, screen_reader_transcript or check_page_alt_text returned a job id instead of a result — never abandon the check, collect it here. Pass the job id the tool returned; if it is still running, call again in a few seconds. The payload is identical to the one the tool would have returned inline — the same fields, the same caps, the same void handling — so nothing has to be parsed differently because a page was slow. The per-response options below are read from this call rather than from the queued run, so a job can be collected with more detail than it was asked for without paying for a second browser run. Read-only.

Use this when the question is whether the site actually WORKS for a keyboard-only or switch-device user — tab order, focus traps, whether the focus ring is visible at all — which no stored scan and no static markup check can answer. Run it before claiming keyboard accessibility for a page, and again after deploying any tab-order, focus or skip-link fix. It tabs through the page the way a keyboard-only user does and reports what breaks: focus traps, elements with no visible focus indicator, focus hidden behind sticky headers, controls that cannot be reached at all, controls that ignore Enter and Space, and tab order that contradicts the visual or document order. Focus indicators are measured by comparing rendered pixels rather than CSS, because indicators come from outline, box-shadow, border and background alike. Findings carry a confidence: the order rules in particular are nudges for a human to confirm, not assertions. A focus-obscured finding names the element doing the covering, once per occluder, and counts distinct covered elements — with stops carrying the tab-stop total when the ring revisits them. A focus-trap finding that may be an open modal behaving correctly says so and says what to check by hand. The response states the viewport the walk was performed in, because the obscured and offscreen results are geometry, and endedBy says which of three things stopped the walk: the ring closing ("ring-closed"), the step ceiling ("max-steps") or the run's time budget ("time-budget"). Only the first means the ring was fully walked. Each finding's selectors array holds up to 5 examples, with count the true total and selectorsTruncated set when more were cut; full: true returns them all from the stored run. A run that lands on a bot-protection interstitial rather than the page is reported as void, never as clean, and a void run carries no stops or findings at all. Where the interstitial title is contradicted by the walk itself, the run stands and carries challengeSuspected instead: trust the walk, not the title. Read-only.

Use this when the subject is images — alt text, image descriptions, 'do our images have alt text' — across the whole site, from the scan already on record. For one page checked right now, including one no scan has covered, use check_page_alt_text. Alt-text problems found on a website's most recent scan: images with missing, filename-like, vague or inaccurate alt text, each with the element selector, the current value, why it was flagged, and a suggested replacement. Scoped to the current scan, not the whole history. Each finding also carries "markupHint": an tag rebuilt from the stored image URL and alt value, so you have something greppable — the selector describes the rendered DOM and appears in no source file. It is a reconstruction, not the markup that was scanned, so treat the src path and the alt value as search strings rather than diffing it against your source. How the counts relate: "rawFindings" is every row on record for the scan, "distinctImages" is how many source images those rows collapse to once per-page repeats and cache-variant URLs of one asset are merged, and "returned" is how many of those are in this response — returned <= distinctImages <= rawFindings, and the work is one alt decision per distinct image. A finding's "affectedImages" is a different kind of number and the one you must not sum: it counts images on that page sharing the finding's template, and every finding sampled from one template repeats it, so three findings reading 7 are one group of seven. "templateGroup" says which findings share a group, and "imagesInAffectedTemplates" is that roll-up already done once per group — quote it as the image total rather than adding anything up. "suggestedAlt" is written from the image alone, by a pass that never saw the page around it: if the image is decorative, or an adjacent link or caption already names the destination, alt="" is the correct fix and not the description offered — validate_fix on image-alt confirms alt="" as resolved. Every suggestion carries that as "suggestionCaveat"; the judge_alt_text prompt is the long version. Read-only — it does not change any alt text.

Use this when the accessibility problem is in the WORDS a merchant wrote rather than in the theme's code — 'click here' links, unlabelled fields, headings that describe nothing — and a writer or merchandiser will be the one editing it, in the Shopify admin rather than a repo. Problems found in the text of a Shopify store's own content — product descriptions, pages, articles, collections: link text that does not say where it goes, controls with no label, headings that do not describe what follows, tables used for layout, and the structural markup rules that can be decided from the authored HTML. Each finding carries the item it is in, the current text, why it was flagged, a suggested replacement where there is one, how confident the judgement is, and an admin link to the exact place to edit. Do not use it for images or alt text — that is list_alt_findings, and the two never overlap. Only Shopify-connected stores have this data; a site with no store connection returns nothing. Read-only: costs one read and loads no page. An empty result is reported together with whether a content review has ever run, because 'never reviewed' and 'reviewed and clean' are different answers and must not be conflated.

Use this whenever a scan-backed answer came back empty or thin and you need to know whether that means 'clean' or 'never checked'. It is the only tool that says whether monitoring is actually working: a page failing every night, throttled, or a whole storefront behind a password produces no data and reads exactly like a site with nothing wrong. The monitored-page inventory for a website: which URLs are watched, which are paused, when each was last scanned, its last score, and which pages are failing, unreachable, throttled or overdue. Also reports how many of the plan's audited-page slots are in use. Read-only from stored state: it loads nothing, costs no page allowance, adds and removes no pages, and shows the last recorded attempt rather than the live state of the site. Monitoring runs about every 20h per page, so a page scanned a few hours ago being "due" is normal, not a fault.

Use this when the ask is to fix, remediate, prioritise or cost accessibility, a11y, WCAG or ADA failures on a site — 'what is broken', 'where in our code is it', 'give me a remediation plan'. It is the free, no-page-load record of what the static scanner found, and the place remediation starts; it is not the whole audit, and what it cannot see is named at the end. The fix list for a website, from its current scan only — not its whole history. One entry per axe rule, worst impact first, not one entry per page: a rule is listed once with "totalElements" (how many elements across the site fail it) and "pages" (each failing page with its own element count). Grouping is by rule rather than by selector because axe writes a different selector for the same element on every page — the same button can be "button[data-product-id=13914]" on one page and ".add-to-wishlist-button" on the next — so selectors cannot identify a shared component. Each entry carries what you need to act: impact, rule id, WCAG criterion, the help text and its documentation URL, and — from ONE example page, named in "examplePage" — the failing HTML, that page's selectors, the computed foreground/background/ratio for a contrast failure, and the AI's suggested fix where one was generated and is trustworthy. For a contrast failure, "contrastData.minimumPassing" is the nearest colour that clears the threshold, with the ratio it achieves — derived arithmetically from the measured colours, so prefer it over any suggested hex. Where a suggestion is held back, "suggestionWithheld" says why rather than leaving the field silently empty. Each entry also carries "grepFor": strings taken from the failing elements across every affected page — ids, distinctive non-utility classes, visible text, image filenames — that are likely to appear verbatim in your source, most widespread first. Search your own codebase for those to find the template. "grepTargets" is the same list tagged with what each string is and how much weight it carries: a "strong" target is content-derived or a distinctive authored name, a "weak" one is a generic class kept only because the element offered nothing better. "nextStep" is built from strong targets alone, and when only weak ones exist it says so instead of naming one — a one-word class can be produced at render time or held in a CMS or configuration value, so it is corroboration and not a location. The CSS selectors describe the rendered DOM and appear in no source file; they are capped at 3 per entry because ten selectors differing only by a product id carry one bit of information. A rule failing on many pages is usually one shared component, but this tool does not claim to know that: it gives you the pages and the example markup so you can check before fixing page by page. What it does give you is an estimate — "distinctCauses", with the shapes themselves in "causes" — computed by normalising each element's selector (attribute values and :nth-child indices removed) and counting the distinct shapes, so 88 failing buttons that differ only by product id come back as roughly one cause. Treat it as an UPPER BOUND on the number of templates and not a measurement: two shapes can be one component that axe named differently on two pages, and one shape can be two components that render alike. Every entry in "causes" carries its OWN evidence — examplePage, htmlSnippet, findingId and, on contrast rules, contrastData with its own minimumPassing — because the rule-level example fields describe one cause and the others routinely differ: a six-cause contrast failure is usually not six instances of one colour. Fix and validate each cause, not the majority one. "totalDistinctCauses" sums them over the entries returned, which is the number that sizes the work; totalElements sizes the symptom. Use it to decide what to fix and where; then validate_fix on the markup you write, before deploying. Each entry says in advance whether that will work: "markupValidatable" false means validate_fix has no markup check for the rule and will refuse it, and "confirmWith" names the check that CAN confirm the fix once it is live — for a keyboard or focus rule that is keyboard_walk, not a rescan, which is the substitution to avoid. "scan" says which run these findings come from and how much of the site it covers: its date, the pages it scanned, and how many pages are monitored against the plan's allowance. Not the tool for alt-text quality (list_alt_findings covers the AI pass) and not the tool for anything only visible in a render — keyboard behaviour, focus visibility, zoom reflow, tap-target size, forced colours and reading order come from keyboard_walk, simulate_condition and screen_reader_transcript, and reading this has run none of them. Reads stored scan results, so it loads no pages and costs nothing against the monthly page allowance. Read-only.

Call this first whenever you do not already know which domains the account holds, or the question names no site. Every website in your Inclusify organisation with its plan, its last recorded score and when that scan ran. Takes no website argument. Works on every plan, including Free and an account holding no websites at all — an empty list is a real answer here, not a refusal, and it means the account has no sites yet rather than that you lack access. Add one with add_website. Read-only.

Use this when the customer wants direction rather than data: 'what should I do', 'where do I start', 'what's most important', 'help me with this site', 'we just signed up'. Also use it before writing any remediation or action plan — it names what is BLOCKING, which is routinely something other than the accessibility findings, and a plan written without it can be entirely correct and reach no visitor at all. Returns an ordered list of concrete next actions for one website, each naming the tool or the panel page that performs it, why it sits where it does, and whether anything below it is blocked until it is done. The ordering is by dependency: a widget that has never reported in outranks everything, a site with no scan on record outranks reading findings, and existing findings outrank upgrading a plan. Steps that need a higher plan are included with the plan named, rather than dropped, so the answer does not quietly become a description of the current plan. What it does NOT do: it performs none of the steps. It starts no scan, changes no setting, installs nothing and charges nothing. It lists no individual accessibility violations either — list_violations and the other finding tools own those, and this points at them. Works on every plan including Free; on a plan without scan data the steps are the account and coverage ones, and the missing scan data is itself named as a step. Read-only: it is composed from site_overview's reads, so it costs about what that call costs and loads no page.

Use this to find the one fix that pays off across every site at once — the shared theme, component or colour token failing on several domains — rather than remediating site by site. Accessibility findings from the last recorded scan of every website in the organisation, worst impact first and grouped by the pattern behind them, so one template fault across forty pages reads as one problem rather than forty. ENTERPRISE plan. Read-only.

Use this when the accessibility question spans the whole portfolio rather than one site — 'where do we stand across our brands', an exec or board summary, which sites are unscanned. One call instead of twenty: the last recorded score for every website in the organisation, the average, and how many sites have never been scanned or are overdue. ENTERPRISE plan. Read-only.

Use this when the question is one URL over time: 'did my fix actually work', 'when did this page break', 'which release dropped this page's score'. It is the only tool that names the scan where a single page regressed. Every recorded monitoring scan of that URL, newest first: score, violations by impact, and how many issue types were fixed and newly introduced since the page's previous scan. Needs a "url"; use score_history for the whole site. Counts are rule-level (distinct axe rules), not element-level, so fixing forty instances of one rule reads as one fixed issue type. The first scan of a URL is a baseline and reports no new/fixed figures rather than zeroes, and so does a later scan that had no earlier scan left to compare with (comparedToPrevious false): its change is unknown, not zero. Read-only, from stored scans: no page is loaded, no page allowance is spent, and a fix deployed since the last scan does not appear. Full-site crawl rows are excluded — if a URL only appears in a crawl, this says so instead of reporting no history.

Use this for any question about plans, pricing, limits or upgrading: 'what plan are we on', 'what does Pro cost', 'what would we get for upgrading', 'is it worth moving up', 'how many pages do we get', 'why can't I use X'. Also use it after any tool refuses on a plan gate — the refusal names the plan required, this says what that plan costs and what else comes with it. Returns every plan with its current price, monthly visitor allowance, audited-page allowance and in-product feature list, all read from Inclusify's live configuration rather than remembered — so do not quote a price from memory, quote this. It also returns where the current plan's allowances actually stand (pages monitored against the allowance, visitors this month against the cap), because 'should we upgrade' is not answerable from a price list alone: a site using a fraction of what it already pays for usually should not. It respects who owns the billing. An invoice-managed website has no self-serve upgrade at all, and this says so rather than offering a link that will not work for them. What it does NOT do: it changes nothing, charges nothing and creates no checkout. It returns no URL either — billing_link owns that. It holds no accessibility data; site_overview owns the site's condition. Works on every plan including Free. Read-only: two indexed reads and one cached config lookup, no page load.

Use this when the user wants to change what a site is CALLED inside Inclusify — tidying up a default name, or matching a rebrand. WRITES to this website's Inclusify configuration, never to the site itself: the display label only. It does NOT change the domain, the website's address, or anything a visitor of that site can see, and no other tool or link starts working differently afterwards: everything here is addressed by domain, not by name. To point Inclusify at a different or additional hostname use add_domain instead — renaming will not do it. Applies immediately, needs no confirmation, and is reversible by calling again. If the name is already what was asked for, nothing is written and the response says so.

Use this when the question is about TIME rather than the site's present state: is our accessibility getting better or worse, did last quarter's remediation move the number, when did the score drop, what did this look like a year ago. It answers trend and nothing else — it names no violation and locates nothing. Accessibility score for a website over time, from the scheduled monitoring scans already on record, with the direction of travel and the change over the window worked out. Per day for up to the last 30 days, where the plan keeps a daily series (Pro and above; below that the daily answer is served per month instead, and says so); per month, from the stored monthly snapshots, for up to 24 months — pass "months" (or granularity "month") for the long view. Pass "url" to follow one page instead of the site; without it each day's point is the mean across the pages scanned that day, so a day with one page scanned is not comparable with a day with ten. Read-only, from stored scans: it loads no page, costs no page allowance, and knows nothing newer than the last monitoring scan — it cannot confirm a fix deployed minutes ago. Full-site crawls are excluded (see crawl_summary); they are dated snapshots, not a series. A website with no scans in the window says so explicitly — that is missing data, never a clean result.

Use this when the question is whether the page still makes SENSE read aloud — the screen-reader, NVDA, JAWS or VoiceOver experience, blind and low-vision users, 'is this usable without sight' — rather than whether it passes rules. Rule checks can all pass on a page whose announcements are meaningless, and no stored scan holds this. It reads the page the way a screen reader does: every announcement in order, with roles, names, states and hints, so you can judge whether the meaning survives being linearised — unlabelled images and icon buttons, controls with no name, text whose reading order contradicts the visual layout. This models Chromium's accessibility tree; it is not a recording of NVDA, JAWS or VoiceOver, which word announcements differently, so do not treat the exact phrasing as ground truth. A run that lands on a bot-protection interstitial rather than the page is reported as void, never as clean, and a void run carries no transcript. Where the interstitial title is contradicted by the tree that was read, the run stands and carries challengeSuspected instead: trust the transcript, not the title. Read-only.

Names the GitHub repository where this site's problems become work somebody can pick up. Reach for it when a developer or a coding agent should be getting issues instead of reading a dashboard. WRITES to this website's Inclusify configuration, never to the site itself and never to GitHub: it records the repository and opens no issues by itself, which file_github_issues does. It CANNOT install the GitHub App: that is an approval screen on the customer's GitHub account reached from the Integrations page of the Inclusify panel, and no assistant can do it, so this refuses until the workspace has an installation. Before saving it checks the App can actually write issues in that repository and saves nothing if it cannot, so a stored binding always works. REQUIRES CONFIRMATION, because the wrong repository puts accessibility work in front of a team that did not ask for it, somewhere a coding agent may act on it unattended. The account owner is emailed a record, including the previous repository. Needs the PRO plan, matching the panel.

Use this when the user wants accessibility findings exported from a site to go to a different Jira project, or is setting one up for the first time. WRITES to this website's Inclusify configuration, never to the site itself and never to Jira — it records which project key exports should use, and files no tickets by itself. It CANNOT connect Jira: authorising Atlassian is a browser OAuth flow on the Inclusify panel's Integrations page and no assistant can do it, so this refuses until the workspace is connected. It also cannot list the available projects — ask the user for the project key, or have them read it off the board. REQUIRES CONFIRMATION, because pointing this at the wrong board sends the work to a team that did not ask for it while the team that did sees nothing, and nobody notices until they ask why no tickets were ever raised. The account owner is emailed a record, including the previous key. Needs the PRO plan, matching the panel.

Use this when the user wants monitoring notifications for a site to go somewhere else, or wants to stop or restart them — routing alerts to a shared inbox, or quietening a site during a rebuild. WRITES to this website's Inclusify configuration, never to the site itself. Three independent settings, all optional: the notification email address, whether regression ALERTS are sent, and whether the periodic DIGEST is sent. Anything you leave out is left exactly as it is, so you can change one without knowing the other two. Pass an empty string for the email to clear the override and fall back to the account's billing address. This REQUIRES CONFIRMATION — call without "confirm" first, show the user the preview, and call again with the token once they agree — because turning alerts off or repointing them is a change that hides its own consequences: the site can regress and nobody hears. The PREVIOUS recipient is emailed a record with a link to undo it, which is deliberate — the person who just stopped receiving these is the one who needs to know. It does not change what is monitored: use add_monitored_pages for that.

Use this when the user wants accessibility alerts for a site to go to a Slack channel, or to a different one than now. WRITES to this website's Inclusify configuration, never to the site itself. It CANNOT install Slack: that is a browser OAuth flow on the Inclusify panel's Integrations page and no assistant can do it, so this refuses until the workspace is connected. It also cannot list channels — ask the user for the channel, by name or by Slack channel ID. NOTE THAT THIS POSTS A MESSAGE to the channel before saving, on purpose: a binding that looks right and posts nowhere is worse than a refusal, because the customer believes they are covered. If the post fails — wrong channel, private channel the app was never invited to — nothing is saved and the reason is returned. REQUIRES CONFIRMATION, because it both writes to their Slack and redirects where alerts go. Changing the channel keeps the existing notification settings; only a first-time binding takes the defaults. Use set_slack_events to change which alerts fire. Needs the PRO plan, matching the panel.

Decides WHICH kinds of finding get announced, once a channel is already chosen. Reach for it to quieten somewhere noisy, or to switch on something a team keeps missing. WRITES to this website's Inclusify configuration, never to the site itself, and nothing is posted to Slack by this call. Four independent switches plus a threshold, all optional: anything you leave out stays as it is. The site must already have a Slack channel — use set_slack_channel first, and this refuses until then. No confirmation is needed to turn an alert ON. Turning one OFF, or raising the score-drop threshold, means nobody hears about that class of problem any more, so those REQUIRE CONFIRMATION. Needs the PRO plan, matching the panel.

Use this when the user wants the accessibility statement they have already written to go LIVE at its public URL, or wants to take it back down. WRITES to this website's Inclusify configuration, never to the site itself — the statement is hosted by Inclusify and the widget links to it. It does NOT write the statement: the shape, the sections and the limitations are filled in through the Inclusify panel, because a statement is a legal representation about the company's own conformance and the wording has to be theirs. If nothing has been written yet, this says so. Publishing is REFUSED, with an itemised list of what is missing, when the statement is incomplete — read that list to the user rather than reporting a failure. Calling this with published:true on a statement that is ALREADY published is not a no-op and is not a mistake — the public page serves the version captured at the last publish, so republishing is how edits made since reach it. BOTH DIRECTIONS REQUIRE CONFIRMATION: publishing makes a legal document about their conformance publicly readable and linked from every page carrying the widget, and withdrawing retracts a document an auditor or regulator may already have cited, after which the page returns 404. Call without "confirm" first, show the user the preview, and call again with the token once they agree. The account owner is emailed either way, with a link to undo it. Needs the STARTER plan, matching the panel.

Use this when the user wants the Inclusify widget on their site to look different — match brand colour, move it off something it covers, change its size or icon — or to change which accessibility PROFILES it offers visitors. WRITES to this website's Inclusify configuration, never to the site's code or theme: it changes what the widget bundle renders. Takes effect within about a minute; the edge cache is purged as part of the change. Every setting is optional and anything you leave out is left exactly as it is, so you can change one without knowing the others. This REQUIRES CONFIRMATION — call without "confirm" first, show the user the preview, then call again with the token once they agree — because the result is visible to that site's real visitors. Removing an accessibility profile is the consequential part: it takes an accommodation away from visitors who may be relying on it, so the preview names each one. Note that "enabledProfiles" is a COMPLETE REPLACEMENT LIST, not an addition — whatever you pass becomes the whole set, so include the ones already on that should stay on. The account owner is emailed a record with a link to undo it. Needs the STARTER plan or above, matching the panel. Shopify-billed stores and Wix-billed sites cannot use this at all — they customise the widget from the Shopify app and the Wix app respectively. To turn the widget off entirely, use set_widget_enabled instead. One setting here needs more than Starter: "hideBranding", which removes the Inclusify wordmark from the widget's footer, needs the ENTERPRISE plan.

Use this when the user asks to switch the Inclusify accessibility widget on or off for a site — turning it on after setup, or taking it down while something is investigated. WRITES to this website's Inclusify configuration — never to the site's code or theme: it sets whether the widget bundle served to that site renders the widget or does nothing. Takes effect within about a minute; the edge cache is purged as part of the change. The two directions are treated differently on purpose. Turning it ON is applied immediately and needs no confirmation. Turning it OFF removes a live accessibility feature from real visitors of that site, so it REQUIRES CONFIRMATION — call without "confirm" first, show the user the preview, and only call again with the token once they have agreed — and the account owner is emailed a record of it with a link to undo it. Idempotent: if the widget is already in the state you asked for, nothing is written, nobody is emailed, and the response says so. This never uninstalls anything: on a Shopify store the widget is a theme app embed and turning it off here does not remove the embed.

Use this for the audit findings a static scanner is structurally blind to: reflow at 400% zoom, tap targets too small on a phone, Windows High Contrast, and prefers-reduced-motion. It belongs in any thorough accessibility audit or remediation plan, not only when someone names zoom or tap targets — a plan that skipped it has not looked at low-vision, magnifier or mobile users at all. Loads the page with a real user setting in force and reports what breaks. Conditions: "forced-colors" (Windows High Contrast — content that disappears, and icons painted as CSS background images, which the mode drops), "zoom-400" (reflow at 400% zoom, emulated as a 320px viewport — sideways scrolling and content hidden at narrow widths), "reduced-motion" (animations that keep running and media that autoplays), "target-size" (tap targets under 24x24px at a phone viewport). Every check is geometric or API-based rather than pixel-based, and each condition reports the viewport it was measured in — they differ, 320px wide for zoom-400 and 390px for target-size against 1280px for the rest — so a geometry finding can be reproduced. Conditions that could not be applied are reported as skipped rather than passing silently. Each finding's selectors array holds up to 5 examples, with count the true total and selectorsTruncated set when more were cut; full: true returns them all from the stored run. Where count exceeds distinctSelectors the same markup repeats, so the fix is smaller than the count. A run that lands on a bot-protection interstitial rather than the page is reported as void, never as clean — conditions, findings and prose together, so a void run never carries numbers. Where the interstitial title is contradicted by findings measured on the page, the run stands and carries challengeSuspected instead: trust the findings, not the title. Read-only.

Start here for any accessibility, a11y, WCAG or ADA question about one website whose current state you do not already know — 'how are we doing', 'is this working', 'are we covered', 'should we worry'. It is the cheapest way to learn what has been measured and how much of the site that covers, which every later tool choice depends on. The whole current position for one website in a single call: plan and whether a trial or failed payment is about to change it, the headline accessibility score and when it was measured, how many pages are being checked automatically against how many the plan includes, this month's visitor count against the plan's allowance, whether an accessibility statement is published, whether the widget is switched on, and whether anything is currently stopping scans from running. "coverage" says how much of the site the score describes: monitored pages, the plan's page allowance, and what the last crawl found against what it scanned — a score measured over one page of a site with 82 discovered pages is a fact about those pages, and the unscanned ones are neither passing nor failing. Then use the finding-level tools for detail. Do not use it to list problems: it reports counts, never individual violations. Read-only: costs one read and loads no page, so it is cheap and safe to call first. It reports what is on record: a site that has never been scanned returns no score rather than a good one, and a missing number never means a clean result. Where the score is missing for a reason other than that — a crawl is running and it is withheld until the crawl finishes, or the plan does not include scan data — scoreNote says so, so a null score is never read as "never scanned". It works on every plan, including Free: where the plan does not include scan data the score, the scan and the coverage come back null with scoreNote explaining which kind of missing that is, and the plan, widget state, page allowance and visitor counts are still reported in full.

Use this when the stored scan covers too little of the site to answer from — one page scanned out of eighty discovered, or a site never crawled — and a site-wide audit is what was asked for. WRITES to this website's Inclusify configuration — never to the site itself: queues one full-site accessibility crawl. The scan worker discovers pages from the website's primary domain and audits up to maxPages of them, which is capped at the plan's audited-page allowance; when a requested maxPages is clamped down to that cap, the response says so. Asynchronous by design: this returns the job id immediately — keep working, then collect the outcome with crawl_summary (progress, coverage, averages, worst pages) and read the findings with list_violations. Safe to retry: if a crawl is already PENDING or CRAWLING it does not start a second one, it returns the running job and its progress. Removes and edits nothing — not pages, not monitoring, not settings. Costs no page allowance; at most 3 crawls per website can be started per day (UTC).

Before deploying ANY accessibility fix, validate it here first — every time, on every rule, not only when you are unsure. It is free, instant, loads no page, and it catches the fix that merely hides the problem from the next scanner. Send the markup you are about to deploy and get a verdict on whether it actually fixes the rule it targets. Four answers: "resolved", "not_resolved" (with what still fails), "masked", or "not_decidable_from_markup". Call it after editing and before deploying, on the rule id and htmlSnippet from list_violations — it reads markup only, so iterating costs nothing against the page allowance. Check the finding's "markupValidatable" first: every list_violations finding carries it, and false means this tool has no markup check for that rule and will refuse it, so the call is wasted. Easiest way to call it: pass "finding" — the findingId from a list_violations entry — and "rule", "before" and the measured colours are filled in from the stored finding for you; anything you pass explicitly wins over them, per field. "masked" is the answer worth having: deleting the element, adding aria-hidden, hiding it with display:none, dropping the visible text or turning a into a all make a scanner go quiet while leaving the barrier in place, so a later re-scan would wrongly agree with you. Never treat it as resolved. Pass "before" whenever you have it — deletion, lost text and downgraded controls are only detectable by comparison. For a contrast rule, pass "colors" — the foreground and background you intend to ship, plus fontSize and fontWeight for large text — and the ratio is computed against the WCAG threshold and answered outright, with the nearest passing foreground when it still fails. Colours declared inline on the markup are read automatically. Without a colour pair contrast stays undecidable, because a fragment has no computed colour. It cannot judge anything else that depends on rendering: focus indicators, forced-colors, reduced motion, tap-target size, reflow at zoom, keyboard traps and reading order all come back "not_decidable_from_markup", naming the tool that can answer them. It also refuses rules it has no check for rather than guessing, so a "resolved" means something. Each markup argument is capped at 100KB; going over is reported, not silently trimmed, and a truncated fix is never called resolved. Read-only — it does not touch the site, the scan history or the findings.

Use this when the question is about the widget itself rather than about accessibility findings: 'is the widget working', 'is it installed', 'why can't I see it', 'did the install work', 'how do I add it', 'is it live for visitors'. Answers with two separate facts that are commonly mistaken for one — whether widget serving is enabled on the Inclusify account (a setting that defaults to ON for every account before anything is installed, so on its own it proves nothing), and whether the widget has EVER been seen on the site — a report from the embed on one of the site's own pages, or a daily monitoring scan that watched it run — which is the only evidence that it is really there. Never report the enabled flag as installation. A site with several domains is answered per domain: domains gives each one's own state, and the site is partial, with missingOn naming the domains, when the widget is live on some of them and not on the others. Never call a partial site live everywhere. When nothing has ever reported in, it returns the exact script tag to paste — or, on a Shopify store, says that the widget is a theme app embed which can only be switched on from the Shopify admin, and on a Wix site, that the app manages the script itself and what is missing is a published site or an unpaused app. No assistant can do those steps. On paid plans it includes what daily monitoring last found on the monitored pages (widget running, script present but not running, or absent); that check is what decides the answer when it is recent. What it does NOT do: it does not fetch the customer's site itself, so on a site without a recent monitoring check it cannot see an embed that has been installed but not yet visited by anyone. It does not switch the widget on or off, and it reports no accessibility findings — site_overview and the finding tools own those. Works on every plan including Free. Read-only: four indexed reads, no page load.

The Inclusify accessibility widget — the overlay Inclusify serves onto the customer's own site — and what visitors do with it. Read this before writing ANY remediation plan for a site where site_overview reports "widgetEnabled": true, and for 'is anyone using this', 'what are we getting for the money', 'which features matter to our visitors', or before a renewal or cancellation conversation. The overlay gives visitors contrast, text-size, spacing, cursor, reading and navigation controls, so an active one is a layer between the site's source and what a visitor experiences, and a plan written from findings alone describes a page nobody sees: some of what you are about to fix is already being worked around at runtime, and a fix at source can duplicate or fight a feature that is switched on. A review wrote a 19-item plan for a store with the overlay live and never mentioned it once. What it returns: per feature, the number of page views in which a visitor switched it on, on how many separate days, the total across all features, and this month's visitor count for context. The unit is page views, not clicks: reporting is deduped per feature per page view, so a slider adjusted repeatedly on one page counts once. Read every count as a floor. Do not use it to judge whether the site is accessible — it measures visitor behaviour, not the site's condition; site_overview and the finding tools do that. Read-only: costs one read and loads no page. Reads zero carefully: a zero total is reported together with which of four causes applies (the widget is switched off in Inclusify; nothing has EVER reported in, meaning the widget is almost certainly not installed on the site at all; visitors were counted before but not in this window; or visitors arrived and feature use has not been reported). A zero of the last kind means only that: no report has arrived. It has two causes a zero cannot tell apart — nobody switched a feature on, or the site is still serving a widget build from before feature reporting existed (bundles are edge-cached for hours and a storefront can hold an older copy for much longer). Never present an empty result as evidence that the widget is unwanted or unused.