Concurrent input

Silktide looks for styles that switch off touch input for the whole page, or that hide buttons and links from people using a particular kind of pointer, such as a mouse or a touchscreen. Pages should let visitors use whatever input their device offers.

Why this matters

People switch input methods constantly: a laptop with a touchscreen, a tablet with a keyboard attached, a desktop with a stylus. Others rely on one specific input because of a disability - a person with tremors may find touch easier than a mouse, whilst someone using a mouth stick may only use a keyboard. A page that disables touch, or that hides controls unless you can hover using a mouse, excludes these visitors from features the rest of your audience can use.

This is the concern behind success criterion 2.5.6 (Concurrent Input Mechanisms), a requirement.

How to fix it

Remove touch-action: none from the html or body element. If you need it to support a custom gesture, apply it only to the specific element that handles the gesture, such as a map or slider, not the whole page.
Where a media query such as @media (hover: none) or @media (pointer: coarse) hides a button or link, ensure the same action remains available by another means for those visitors. Restyle controls for touchscreens rather than removing them.
If the flagged style is genuinely harmless - for example, it hides a control that has an equivalent visible to everyone - you can the finding.

/* Problem: disables touch input for the whole page */
body {
  touch-action: none;
}

/* Better: limit it to the element that needs custom gestures */
.map-canvas {
  touch-action: none;
}

How Silktide tests this

Read the written directly into each page, both <style> blocks and style attributes on the html and body elements.
Report a page when it disables touch globally, with touch-action: none applied to the html, body, or root element.
Report a page when a media query that tests hover or pointer type (such as hover: hover or pointer: coarse) hides an interactive element like a button, link, or form field with display: none.
Report at most one finding per page. Because these patterns sometimes have legitimate uses, findings are flagged for your confirmation rather than counted as confirmed failures.

Troubleshooting

The flagged style is intentional

Some pages have a real need for these patterns - a drawing tool may disable native touch gestures, or a desktop-only feature may hide its hover menu on touchscreen devices whilst offering an alternative route to the same content. If you confirm an equivalent input path exists, approve the finding.

My page restricts input but wasn't flagged

Silktide only reads CSS written into the page itself; rules in separate linked stylesheet files are not scanned by this check. It also cannot see input restrictions applied through , such as scripts that ignore touch events on certain devices. A pass here does not guarantee the page meets the criterion.