mbiletech
mbiletech
Home / Mobile UX / Silktide V4 vs V5: How to Read Your November Score

Silktide V4 vs V5: How to Read Your November Score

Compare Silktide V4 and V5 correctly, trace changes to the November crawl, and verify the mobile accessibility issues worth fixing.

A thumb hovers over two phone controls beside circular measuring guides.

Primary topic Mobile UX

On November 13, 2026, the Silktide Accessibility Index announced a new testing engine and a second score. Its November edition shows V4, the historical measure, alongside V5, which starts a new reporting series. Both still run from 0 to 100, but they assign different importance to the same findings. Start with the score label: two different November numbers can describe the same scan. If V4 itself moved since October, check which pages the scanner could reach and what it found on them.

Which comparison answers your question?
Signal Check Action
November V4 differs from V5 Scoring and PDF scope Keep separate reporting series
V4 moved since October Coverage and changed checks Reproduce the affected finding
V5 alone is missing V5 recording gap Leave blank; check next test
Neither score appears Site access and crawl logs Check refusals and challenges
A phone task breaks The failing control Fix and retest the task

One November scan, two ways to count

Keep your V4 time series for reports that go back before November. Start a separate V5 series with the November value. For a comparison with a peer, use the same edition, category and score version. The Index runs monthly and covers nearly 15,000 sites, but the rank is relative to the sites in the chosen category. Your rank can move while your own score barely changes.

Both versions apply automated WCAG 2.2 checks to the same November scan. The public scoring rules give V4 four weighted categories: A (45), AA (40), AAA (15) and mobile (10). Those are relative weights, not four percentages of the final score. V4 scores each level on its own checks, so its AA result can exceed its A result. V5’s level results are cumulative: AA includes A, and AAA includes both. A V5 AA score therefore cannot exceed its A score.

V5 starts at 100 and deducts points for each check according to the severity of the check result and the check’s maximum impact. A check is counted once in the overall score even if it belongs to several levels. The largest-impact checks retain their previous impact; the other impacts draw on priority and how confident the test is that it found a real issue. Repeated failures on a shared component can affect a check more than a single instance on one page.

The calculation is deduction = impact × (100 − check score) / 100. The official example uses a check with a maximum impact of 10 and a result of 70 out of 100. The shortfall is 30%, so V5 takes off 3 points. If that’s the only deduction, the total is 97. Put that figure in the November V5 column. Comparing it with an older V4 result would mix a new scoring rule with whatever happened to the site between scans.

There are differences in coverage too. Public V4 includes PDFs, while public V5 scores web pages only: its newer PDF checks do not run in the Index. If you maintain forms or guides as PDFs, keep a separate document queue even when V5 improves. The public scan sees the site as a first-time visitor and ignores exceptions your team approved in its own account. A private account can also scan more pages and run additional checks. Label exports accordingly.

What if V5 is missing?

Leave the V5 value blank. When V4 is present but V5 is absent, the V5 result was not recorded for that test; the site has no V5 rank that month and should reappear after its next test. Check that next result before treating the gap as a crawling problem.

V4 is still displayed first. Its retirement is planned for 2027, with advance notice and no fixed date yet. Keep both series until a firm switchover date is announced.

Why V4 can move even if the site stayed put

The V4 formula stayed the same, and Silktide expects most V4 results to remain close to October’s. October was the last Index edition on the previous engine. November retested every site from scratch with the engine already used for customer accounts since October 2026. It can load and test a different set of pages. Most sites are sampled on 25 pages, with an upper limit of 125, and the sample can change month to month. After a redesign, inspect the templates that changed. If you didn’t deploy anything, check coverage and the underlying finding before filing a regression.

Start with the report’s scan date and page count. Then check your release log for new templates, banners or widgets that ran during the scan. When you have the tested URLs, compare the common pages and look at which kinds of pages entered or left the sample. Twenty-five pages can include mostly articles one month and more product or category pages the next. If you can’t recover the original sample, use a fixed internal set for the next comparison and keep the public series labeled as a sample.

The new engine backs off after refusals: it halves concurrent requests, waits and retries. It recognizes browser challenges, records pages it still can’t load as rate limited and leaves them out of the score. It stops waiting for slow decorative backgrounds and records why remaining pages cannot be tested. The older engine could end up testing an error page or fail to reach enough pages to produce a score. Silktide identifies blocked or throttled automated visits as the likeliest cause of a sharp V4 move; check that branch first when your release log is quiet. In a vendor test of 500 Index sites, 37 that previously lacked enough pages became scorable; 13 moved in the opposite direction. If both scores disappear, check CDN and firewall logs around the scan window for 429 responses or challenge pages. The scanner now comes from different servers. Confirm what was served before changing a security rule.

The corrected checks can move either score even on pages that loaded successfully. Use the changed check to choose the retest, rather than opening a generic “score dropped” ticket.

Which November correction matters to your site?
Feature Change Action
Duplicate IDs or malformed lists 4.1.1 exits score Review markup separately
color-mix() or wide-gamut colors Correct color values Recheck previously flagged text
Open shadow roots Checks and links inside Inspect newly tested components
Visible CSS child Now tested Inspect the visible child
Small, separated controls Correct spacing geometry reduces false failures Measure nearby targets
::after focus ring Ring detected Recheck the flagged focus state
Silktide cookie banner Hidden-focus false flag fixed Test focus inside banner
PDF image alt text Check removed Keep auditing documents

Use a target-size finding to pick the first mobile fix

The November report for Warehouse, a UK fashion retailer, shows what a public result gives you. The scan assessed 25 pages on November 6. Under Recommendations it lists “Ensure interactive components are far enough apart,” WCAG 2.2 AA 2.5.8, with progress of 2%. That progress value describes the tool’s check result across the tested sample, rather than the proportion of shoppers who can use the site. It identifies a class of touch controls to investigate. To act on a similar report for your own site, find a representative page and reproduce the flagged control at a narrow viewport.

The November engine now uses the 24 CSS pixel circle in the WCAG spacing test. For an undersized target, center the circle on its bounding box; it must avoid other targets and the circles around other undersized targets. If your isolated mobile toolbar has two 18 by 18 CSS pixel buttons with centers 20 pixels apart, their circles overlap by 4 pixels. Move their centers to 28 pixels apart and those circles have a 4-pixel gap. That clears the spacing test for this pair, assuming no other controls intersect. For frequent actions, enlarge the actual tap area to at least 24 by 24 CSS pixels by default; use spacing when the layout prevents that. The icon itself can stay small.

Target spacing for two undersized controls Two 18 by 18 CSS pixel square targets. Circles of diameter 24 overlap by four pixels at center spacing of 20, and leave a gap of four at spacing of 28. 20 px apart: fix spacing 4 px overlap 28 px apart: circles clear 4 px gap 18 × 18 px targets · 24 px circles
Illustrative pair of targets, drawn at the same scale. Clearing this pair does not clear its other neighbors. Source: WCAG 2.2 target size and spacing.

The other exceptions to 2.5.8 cover an equivalent conforming control on the same page, inline targets, unmodified browser-controlled targets, and an essential or legally required presentation. Check these before redesigning a flagged element: a link within a sentence is a different case from a toolbar button. CSS pixels are layout units, not the phone display’s physical pixels.

Check the live state where the control matters. A quantity button can have enough room on the product page and sit too close to Remove once the mobile cart is open. Measure the clickable element, not the icon. If you fix a shared component, test it in the page that raised the finding and in another template that uses it. For focus findings, tab through the opened dialog and back to its trigger; an interactive accessibility check captures failures a snapshot can’t.

A public result of 100 means the scan found no issues it could score. Checks that require judgment don’t contribute to either number. Use human evaluation to decide whether someone can complete the journey, and keep the benchmark as a separate reporting measure. In the issue ticket, record the month and score version, the page and viewport, the check that changed, and the action a reader or shopper couldn’t finish. Assign the fix to the owner of that component and repeat the same task after the change.