Search topics
Full-page sections that Page Down and Space can't move
A script changes full-screen sections on wheel and swipe events and locks the page, so Space, Page Down and the arrow keys move nothing.
window.addEventListener('wheel', …) The problem
Keyboard users see the page's first screen and can't bring the next ones into view
A product page for a pair of headphones is drawn as four full-screen sections: the name, the battery, the repairs, and the price with an "Order now" link. One notch of the mouse wheel, or one swipe, slides the next section into place, and nothing stops halfway. It is a popular look for a launch page, and with a wheel it feels good.
A keyboard user loads the page and presses Space. Nothing moves. Page Down, the down arrow and End do nothing either. Tab goes straight to "Order now" in the last section, because it is the first thing on the page that takes focus, and the battery and repairs sections are passed without ever being on screen.
Nothing on the first screen says there is more. overflow: hidden removes the scrollbar, and a section that fills the window leaves nothing cut off at its bottom edge.
Success criterion 2.1.1 asks that all functionality can be operated through a keyboard. A browser normally gives a page this for free: Space, Page Down, the arrow keys, Home and End scroll any page that can scroll. This page has been told it can't. overflow: hidden on html and body leaves the browser nothing to scroll, and the sections move by a transform that only a wheel listener and a swipe set.
The W3C calls this failure F54: pointing-device-specific event handlers as the only way to run a function. The criterion doesn't name particular keys. It asks for a keyboard way to do the same thing, so a page with buttons that choose each section can pass it, as one fix below does. This page has no keyboard way to the middle sections at all.
Tab doesn't rescue it. Sections of plain text have nothing to focus, so Tab can't stop in them. When it reaches the link, the browser scrolls the locked body to bring the link into view, which the script knows nothing about, so the next turn of the wheel leaves the page out of step with its own count of sections.
The page works with a mouse and, where swipes are handled, on a phone, so it can ship without anyone trying the keys.
5 of 10 groups affected
- No vision (affected)
- Low vision (affected)
- Colour vision (not affected)
- No hearing (not affected)
- Hard of hearing (not affected)
- No speech (not affected)
- Motor (affected)
- Reach, strength (affected)
- Cognitive (affected)
- Seizures (not affected)
- Limited manipulation Keyboard and switch users press Space, Page Down and the arrow keys, and the first screen stays where it is. Tab jumps to the first link in the page, past any section that holds nothing to focus, so they never see the text in those sections.
- Limited reach and strength People who find a mouse wheel or a swipe hard to manage turn to the scrolling keys, and those keys move nothing here.
- Limited vision People who zoom in make the text bigger while each section stays one window high, so text can run past the window or into the next section, and no key brings it into view.
- Without vision When the script hides the sections it isn't showing with visibility: hidden, as an Observer demo in GSAP's documentation does, they are out of the accessibility tree, so a screen reader has only the section on show to read.
- Limited language, cognitive and learning abilities Nothing on the first screen shows there is more: no scrollbar, and nothing cut off at the bottom edge. Someone who takes that screen for the whole page has no reason to look further, and misses the price and the link to order.
The markup is valid and every section's text is in the page, so axe and other markup checks pass it. The EaseWeb audit presses the keys: with focus on the page, it presses Page Down, Space, the down arrow and End, then Tab and Page Down again, and then turns the wheel. Content that moves for the wheel and for no key is reported as ew:scroll-keys-manual-check. So is a page whose scrolling stops short of its end while the keys are still pressed. It is a review lead and not a finding, because buttons elsewhere on the page can give the keyboard a way to every section, and code can't weigh them. AI fixes can add a listener for the arrow keys alone, which leaves Space, Page Down, Home and End dead, or add tabindex="0" to the sections, which gives Tab somewhere to stop and moves nothing.
Try it
Click the page, then reach every section from the keyboard
A mouse wheel or a swipe moves the page. Do Space, Page Down and the arrow keys? Press Tab too, and watch which sections you pass. Then apply a fix and try again.
Broken Can you fix this?
Aster One
Headphones that fold flat.
Thirty hours on one charge
Ten minutes of charging gives you three more.
Made to be mended
Every part can be replaced, and the repair guide is free.
$199
Free delivery and 30 days to return them.
Order nowThe fix
Let the keyboard move the page as the wheel does
<main class="screens"> <section> <h1>Aster One</h1> <p>Headphones that fold flat.</p> </section> <section> <h2>Thirty hours on one charge</h2> <p>Ten minutes of charging gives you three more.</p> </section> <section> <h2>Made to be mended</h2> <p>Every part can be replaced, and the repair guide is free.</p> </section> <section> <h2>$199</h2> <p>Free delivery and 30 days to return them.</p> <a href="/order">Order now</a> </section></main>What is wrong4 points
overflow: hiddenonhtmlandbodyleaves the browser nothing to scroll, so Space, Page Down, the arrow keys, Home and End move nothing.- Only the wheel and a swipe call
show(). No key does. - Tab goes straight to "Order now", past the two sections with nothing to focus.
- When it gets there, the browser scrolls the locked
bodyto show the link, and the script's count of sections no longer matches what is on screen.
The browser scrolls, and the sections settle into place
<main class="screens"> <section> <h1>Aster One</h1> <p>Headphones that fold flat.</p> </section> <section> <h2>Thirty hours on one charge</h2> <p>Ten minutes of charging gives you three more.</p> </section> <section> <h2>Made to be mended</h2> <p>Every part can be replaced, and the repair guide is free.</p> </section> <section> <h2>$199</h2> <p>Free delivery and 30 days to return them.</p> <a href="/order">Order now</a> </section></main>How it is fixed3 steps
- Remove
overflow: hiddenand the script. The page scrolls again, so Space, Page Down, the arrow keys, Home and End all move it, and Tab brings each link into view, with nothing to write. - Put
scroll-snap-type: y proximityonhtmlandscroll-snap-align: starton each section. Space and Page Down now land on the next section, as a turn of the wheel did. - Change
heighttomin-height, so a section that needs more room at high zoom or on a small screen grows, and the keys scroll through it.
This fixes the Before and passes 2.1.1 with no script at all. The sections can still animate as they arrive, with an animation tied to the scroll position, which leaves the keys to the browser.
All three pass 2.1.1, and only the first passes with no conditions, which is why it is the one to choose. The browser's own scrolling takes every scrolling key, Tab and touch, with no script to keep working, and the sections can grow when someone zooms. What it gives up is exact control: a page can come to rest between two sections, and the movement is the browser's own, not a timed slide. Keep the script only if that slide is the point of the page, and then add the keys, as the second fix does. Treat the buttons as the quick repair for a page you can't rebuild yet, or as an addition to either of the others.
Most of the scroll libraries checked here don't have this failure, so check yours before rewriting anything. With default settings, in Chromium, Firefox and WebKit in November 2026.
- fullPage.js 4:
keyboardScrollingis on by default. Space, Page Down, the arrow keys, Home and End change the section, and a section taller than the window scrolls first. Don't turn it off. - Lenis 1.3, Locomotive Scroll 5 and GSAP's ScrollSmoother: they ease the wheel and leave the keys to the browser, so the keys work. Locomotive Scroll 4 in its smooth mode handles the keys itself, and they moved the page in all three.
- GSAP's Observer: it listens to wheel, touch and pointer events and no keys, so a page built on it, like the section demo in its documentation, is this guide's Before. That demo also hides the other sections with
visibility: hidden, so Tab can't reach them either. - Swiper 14 with
direction: 'vertical'andmousewheel: true: its keyboard option is off by default, so no key moves it.keyboard: { enabled: true }adds the arrow keys, Page Up and Page Down, and leaves out Space, Home and End. With clickable pagination, its bullets are Tab stops that Enter activates only where its A11y module is loaded: the full bundle has it, and a build from separate modules has to add it.
A pinned section can fail the same way. Pinning by itself is fine: a section held in place by position: sticky in a tall wrapper, or by GSAP's ScrollTrigger with pin and scrub, follows the page's scroll position, so Page Down moves through its steps. It fails when a script steps through the section on wheel events and forces every other scroll back to where the page was frozen, a pattern answers on GSAP's forum use to stop momentum scrolling. Recreated and run in all three engines, the page scrolled down to the section, then no key moved it in either direction, and only the wheel got past. Choose the step from the scroll position instead.
Scroll snapping is not the cause. A section taller than the window can still be read with scroll-snap-type: y mandatory, since the CSS specification lets the page scroll freely inside a snap area larger than the window, and the arrow keys did so in all three engines. Page Down and Space did too in Chromium and WebKit, but in Firefox they jumped from the top of a tall section to the next one, so use proximity, which walked through it in all three. With mandatory, don't snap to a heading inside a long section: the specification warns that the content in between can become inaccessible, and in a test in all three engines neither the keys nor the wheel could stop in it.
Show that the page goes on. No success criterion asks for this, so it isn't part of passing 2.1.1, but a section that fills the window looks complete. Nielsen Norman Group calls this a "false floor", and says large hero graphics "offer no additional cues to invite users to scroll". Its advice is to let the next content show at the bottom of the screen, which a section a little shorter than the window does. A scrollbar helps too, though some systems hide it until scrolling starts. A down arrow does the same job if it can be seen before anyone scrolls. Make it a real link or button to the next section, so it gives a keyboard a way on as well. With the section buttons fix, the buttons already show there is more.
Design ideas
A full-screen page can show there is more, and let everyone get there
Six ways to draw the first screen of the headphones page. Look at each before touching it, then put the mouse aside and try it with the keyboard: four go on from the keyboard, and two only with a mouse.
In the design file
- Draw the first screen at the height of a real window, on a laptop and a phone, and check that something on it shows the page goes on.
- Keep the cue in sight before anyone scrolls, not only on hover.
- Draw an arrow or a word as a link to the next section, with its focus ring, at 24 by 24 pixels or more.
- Write the contrast beside the cue, at least 3:1 for an arrow and 4.5:1 for a word.
Passes
Aster One Headphones that fold flat. Thirty hours on one charge Ten minutes gives you three more. Made to be mended Every part can be replaced. $199 Free delivery and 30 days to return them. The next section showing at the bottom The first screen stops short of the window, so the next heading sits cut off at the bottom edge and the eye expects more. Nothing extra to draw, and the browser’s scrolling takes the keys. It gives up the look of one perfectly filled screen.- A round arrow that is a link A 44px round arrow at the foot of the screen, navy on amber at 9.57:1, in sight from the start. It is a link to the next section, so Tab stops on it and Enter goes there, as a click does.
- Aster One Headphones that fold flat. ScrollThe word “Scroll” with a line A quiet editorial look: one small word and a thin line down from it, at 13.95:1 on the paper. The word says what to do, for anyone who wouldn’t read an arrow as an invitation. Like the arrow, it is a link to the next section.
- Named sections down the side Battery, Repairs and Price beside the screen say how much there is and what is in it, which an arrow can’t. Each is a link, and a 3px bar marks the current one. It needs room, so on a phone it moves under the screen.
Fails
- Aster One Headphones that fold flat.An arrow that is only a pictureWCAG 2.1.1 The arrow says there is more, and then only the wheel can go there: it can’t be pressed, and no key moves the screen. Turn the wheel over the sample, then try the keys.
Rule of thumb: Make a gesture a shortcut, never the only way
- Aster One Headphones that fold flat.Dots that come out on hoverWCAG 2.1.1 A clean screen until the mouse arrives. The dots are real buttons, but while they are hidden they take no focus, so Tab passes them by, and until then nothing shows there is more.
Rule of thumb: Make a gesture a shortcut, never the only way
Verify the fix
5 checks, no mouse.
Test with: Keyboard, Zoom, Screen reader
Record the OS, browser and assistive-technology versions, the build, the date, and the actual result of each step. Repeat after changing the page's sections or updating the library that moves them.
Limits
This is a starting pattern, not a guarantee for every application. It covers a page whose own scrolling a script has taken over. A page-sized box with overflow-y: scroll is a different failure: its keys do nothing until focus is inside it, as in scrollable areas that a keyboard can't scroll. A long list that loads more as it scrolls is in infinite scroll that moves the footer away as Tab nears it, motion that can't be turned off in animations that ignore the reduced-motion setting, and a focused control under a bar in sticky headers and banners that hide keyboard focus. A link that takes focus out of view while a script holds the page still can't be seen either, as in missing focus indicators on custom buttons; fixing the scrolling fixes that too. The libraries were tested with a keyboard in desktop builds of Chromium, Firefox and WebKit, not in Safari itself, on a phone or with a screen reader.
This is a recreated teaching example, not a finding about a named client. The code is a starting pattern: test it in your own product. No completed assistive-technology test is claimed here.
References
- WCAG Understanding: keyboard (opens in a new tab)
- WCAG Technique F54 (opens in a new tab)
- w3.org: css-scroll-snap-1 (opens in a new tab)
- developer.mozilla.org: scroll-snap-type (opens in a new tab)
- developer.mozilla.org: overflow (opens in a new tab)
- developer.mozilla.org: visibility (opens in a new tab)
- gsap.com: Observer (opens in a new tab)
- swiperjs.com: swiper-api (opens in a new tab)
- alvarotrigo.com: docs (opens in a new tab)
- nngroup.com: illusion-of-completeness (opens in a new tab)
EaseWeb service
Fixed it? Keep it from coming back.
I turn guides like this one into rules your coding agents follow and checks your CI runs. Then I retest by hand with a keyboard and screen readers, periodically.