Swipewalk for VS Code

See the accessibility findings from a saved Swipewalk scan on the source lines they likely come from, without leaving your editor.

Swipewalk scans a running Android or iOS app (with first-class .NET MAUI support) and writes its findings to a results.json file. This extension reads that file. Hover a marked line to see the problem, who is affected, the WCAG 2.2 criterion, the confidence of the match and the suggested fix.

Preview. This is the first version. Automated checks find only some accessibility issues, so a run with no findings has not been shown to meet any standard. Manual testing with assistive technology is still required.

What it never does

• It only reads a saved run. It never changes your code, never edits the run, and never starts a scan or contacts a device, apart from unpacking a shared file into its own storage.
• It is local only: no network calls, no telemetry, nothing sent anywhere.
• It never tells you a project is or is not compliant. Findings are possible issues found by automated checks.

Get started

1. Scan your app with Swipewalk and point the scan at your project folder so findings can be matched to source: swipewalk scan --platform android --package com.example.app --source <your project folder> (--source is an option of the command-line tool's scan and record; the desktop app's New scan has the same as its optional App source folder. swipewalk export --source adds lines only to the exported files, not to the saved run this extension reads). Without a source folder you still get a findings list, but no lines are marked.
2. Open your project folder in VS Code.
3. Run Swipewalk: Open run… and choose a run. The list shows every run it can find in one place, grouped by app and version, newest first, each labelled with where it was found, and nothing is chosen for you. To open something the list does not show, such as a .swipewalk file a teammate sent you, choose "Choose a file or folder…" or run Swipewalk: Open run from a file or folder….

Markers appear in the files the findings map to, and the Swipewalk view in the activity bar lists everything.

What you get

Markers in your files. Each mapped line shows in the editor and the Problems panel, from source "Swipewalk". The level says what kind of result it is, never how serious it is, and no result is ever an error:

Every line marked by default is at least Information so it also appears in the Problems panel; VS Code lists hints only as faint dots in the editor. A likely match is a best guess, so a possible WCAG issue is shown one level lower than an exact match and every likely message says "Likely match". When Swipewalk could only narrow a finding to several candidate lines, no line is marked (none is known to be right); the candidates are listed in the Findings view, and you choose one. If you turn on swipewalk.showCandidatesAsHints, each candidate line gets a faint hint (editor only, not in the Problems panel).

A rich hover. Hover a marked line for the problem, who is affected, the criterion with a link to the W3C explanation, which laws and standards it is relevant to ("Relevant to ADA Title II, Section 508 and N more", worked out from the list saved in the run, as in the Swipewalk reports), how sure the match is and why, and the suggested fix. The code example appears only for an exact match, and is labelled an example, not a patch. Actions: show details and screenshot, open in report (for runs in your Desktop history), copy ticket text.

The Swipewalk view.

• Run: which run is open, where it was found, when it was scanned, for a shared file its signature notice and what the sender wrote, and the reminder that Swipewalk only knows the screens in that run.
• Findings: grouped by screen, check, source file or who is affected; filter by kind, exact or likely match, and team marks; search by any words. Select a finding to go to its line; the eye button opens its details.

The details page. The screenshot with the element outlined, the predicted screen reader text (predicted from the accessibility tree, not recorded), the source location and any candidate lines, the standard, the full list of laws and standards it is relevant to (grouped by region, with each official link, the laws chosen when the run was saved, "Laws that matter to me" in the desktop app or --my-laws, first within each region; reference information, not legal advice), whether a finding was seen in light or dark appearance or in portrait or landscape, and the suggested fix. Go to source and Copy ticket text are buttons at the top of the page, plus Open in report for runs in your Desktop history.

Status bar. Counts for the open run. Select it to show the findings.

Runs other people shared

A run can be saved as one .swipewalk file and sent by any means you already use. You can open one, a results.json, or an unpacked run folder.

Checked so far by unit tests: with .swipewalk files the tests build themselves, and with the shared test files made by Swipewalk's engine (good and hostile ones). The integration tests that open a real VS Code do not open shared files, and nobody has yet tried opening one by hand in a VS Code window.

Where the list looks. It combines runs from three places, plus anything you open by hand, and labels each one:

• Desktop history: Swipewalk's default History folder on this computer. If you chose another location in the desktop app (History > Change location…), set swipewalk.historyFolder to the same folder.
• Workspace: the accessibility/runs folder of your open project. Teams can commit .swipewalk files or unpacked run folders there and everyone finds them without setup.
• Additional location: any folders you list in swipewalk.additionalRunLocations (absolute paths), for example a shared drive. Only the folders you list are searched, and only a few levels down.
• Opened file: something you chose by hand.

If the same run turns up in more than one place, it is listed once: the copy that has screenshots, then the most recently shared one. Symbolic links inside those folders are never followed.

Opening a .swipewalk file. The file is checked before anything is used. It is refused if it is malformed, larger than your limit (swipewalk.maxRunFileSizeMb, 200 MB by default and never more than 2 GB), made of unsafe file names, unzips to far more than its size, or has any file that does not match the size and SHA-256 hash it lists. A file made by a newer Swipewalk opens with one short note when it can still be read, and is refused with the version you need when it cannot. The contents are unpacked into the extension's own storage, never into your project, and nothing in the file is ever run. The unpacked copy, including any screenshots, stays in VS Code's storage for this extension until you run Swipewalk: Remove opened copies of shared runs (it says how many copies and how much space, and asks first; a shared run that is open is closed; your .swipewalk files are not touched). Opening the same file again reuses its copy and says "Already opened"; a different file with the same run id is unpacked beside the earlier copy, never over it. A shared file never opens a report (a shared file carries none, and a file with an .html entry is refused), and runs found outside your Desktop history don't open their saved report either (including your own scan --out folders), as a safe default; the findings list shows the same findings, and the full report is in the Swipewalk desktop app.

The signature notice. A run can be signed. The Run view and a message say which of these applies. It is a notice, not a block: the run opens either way, and you can close it with Swipewalk: Close the run.

For the last three (not signed, did not match, or a format this version can't check) a message asks "Import this file anyway?" before the file is unpacked; Don't import (the first button; Escape or closing the message also chooses it) opens nothing. How this dialog behaves has not yet been tried in a real VS Code window.

A signature shows which key signed the file and that the file has not changed since. It does not show who the person is: check the key's full 64-digit fingerprint with its owner (hover the Signature row in the Run view to see it in 16 groups of 4; the short XXXX-XXXX form is only for recognising it), then trust it with the command line's swipewalk keys trust. It does not stop a recipient passing the screenshots on, and the file is not encrypted. Trusted keys are read from two places: the per-user list that swipewalk keys trust keeps (trusted-keys.json in Swipewalk's user folder), and the project's accessibility/team-keys file (one key fingerprint of 64 hexadecimal digits per line, then an optional label; # starts a comment), which is read only when you have trusted the folder (Workspace Trust) and only from the top of each workspace folder. Anyone who can change accessibility/team-keys can add a key to it, so review changes to that file like code. The extension only reads these lists; it does not add keys to them.

Read only. The extension never edits a run. Team marks inside a shared file are shown as the sender saved them, marked "in the shared file", and nothing is merged into your own marks. Text that came from the file (app name, messages, notes, who shared it) is cleaned of hidden characters and shown as plain text. What the sender wrote when sharing is shown as "Sender wrote: …"; Swipewalk does not check it.

Commands

All commands are in the Command Palette under Swipewalk. None has a default keyboard shortcut, so nothing clashes with your own; you can bind any of them in Keyboard Shortcuts.

Settings

Keyboard and screen readers

The extension uses VS Code's own surfaces (Problems, hover, views, quick picks, commands), so keyboard navigation, zoom, themes, high contrast and screen reader mode come from VS Code. Every item in the Findings view has a text label and a spoken description that includes its kind, its match confidence and its line, and meaning is never carried by colour alone. The details page uses proper headings and labelled controls, moves focus to its heading when it opens, and announces actions such as "Ticket text copied" through a live region. It uses only VS Code theme colours and follows high contrast themes.

This has not yet been reviewed with people who use screen readers every day, and it has not yet been tested with NVDA, VoiceOver or VS Code's screen reader mode. What is described above is checked by automated tests only, and no person has tried it in a VS Code window. Please tell us what does not work.

How lines are matched, and what can be stale

Swipewalk matches an element to a line by its identifier or its text. Exact means it found a unique match. Likely is a best guess: check it is the right element before changing anything. Candidates means several lines fit. Not found means nothing in the source folder fit, for example a third-party control. Your source may have changed since the scan, so line numbers can drift; every hover shows the run's date and version. A run only covers the screens it scanned; Swipewalk cannot know which screens the app has.

Team marks

If your team marked findings in Swipewalk (won't fix, false positive, accepted risk, each with a reason), the extension shows those marks. On a run saved in results format 0.8 that is every marked finding; on an older run only findings that repeat across the run can be matched to a mark, and the rest show no mark here (the report and the desktop app show them all). It never creates or changes a mark; use the Swipewalk desktop app or swipewalk triage for that. A won't-fix or accepted-risk mark means the team chose not to fix the issue for now. It does not mean the issue meets WCAG.

Where it runs

Written to run on macOS, Windows and Linux (plain TypeScript, no native code) in VS Code 1.90 or later. So far it has been checked on macOS only, by unit tests and by nine integration tests in a real VS Code (version 1.140.0, 2026-10-01) that cover registering the commands, markers and their levels, no marker for candidate lines, the hover, Open in report, Copy ticket text, the next-finding command, an older results format and a refused file. The Swipewalk view, the details page and opening shared files are covered by unit tests only. It has not been run on Windows or Linux, in a remote window, or in other VS Code-based editors, and no person has tried it in a VS Code window.

Source paths are saved relative to the project folder given with --source, so a run made on one computer is designed to open in a workspace on another. Newer runs (results format 0.8) also record that folder's name, and the extension uses it to find the project among your workspace folders. If more than one folder could be the project, or none matches, you are asked once and the choice is remembered.

It runs where your workspace runs (a workspace extension). In a remote window, WSL or a dev container it reads the History folder of that remote machine, so open a copied results.json with Open run from a file or folder… or set swipewalk.historyFolder. A .swipewalk file opens the same way. Web editors such as vscode.dev are not supported.

Reference: the results file

The extension reads results.json written by Swipewalk: results format 0.8, and the older 0.x formats without the newer fields (a finding id, who is affected and the report link are then taken from what the older file holds where possible). A file from a newer major format is refused with a plain message. It reads only the fields it needs. Besides the run folder (results.json, run.json, triage.json, report.html and screenshots), it reads only files in your project, .swipewalk files and run folders in the locations above, and the trusted-keys lists. The only thing it writes is the unpacked copy of a shared file, in its own storage. A .swipewalk file is a zip with a fixed layout (a manifest, an optional signature and one run folder); the extension reads it with Node's built-in zip support and cryptography, with no extra libraries.

Licence

Free to use under the Swipewalk License (the LICENSE file in the extension), the same as Swipewalk 0.4.2 and later. The source code is not public. Not legal advice; the extension reports what automated checks found.