Accessible Observer-Driven Interfaces

Every observer-driven feature changes the page because of where the viewport is, not because the user pressed anything. That is convenient for pointer users and quietly hostile to screen-reader and keyboard users, who may never move the viewport the way the feature expects — so each of these features needs an accessible path designed in, not bolted on.

Concept Framing

The patterns in the Implementation Patterns section share one assumption: the user scrolls, content enters the viewport, and the page reacts. Assistive technology breaks that assumption in several ways.

• Screen readers move a virtual cursor, not the viewport. Many screen readers do scroll the page to follow the cursor, but not always, not smoothly, and not in a way that reliably crosses a sentinel element at the bottom of a list.
• Keyboard users move focus. Tabbing into a list scrolls the focused element into view, which triggers observers — sometimes in the middle of a list, loading content around the focused item and shifting it.
• Content that appears silently is invisible to non-sighted users. A new page of results appended by an infinite scroll sentinel produces no announcement; the user does not know it exists.
• Content that moves unexpectedly breaks orientation. Screen magnifier users see a small region of the page; a reveal that shifts or a list that grows above them loses their place.

The WCAG success criteria most often implicated are 2.1.1 (Keyboard), 2.4.3 (Focus Order), 4.1.3 (Status Messages), 2.2.2 (Pause, Stop, Hide) and 2.3.3 (Animation from Interactions). None of them forbid observer-driven UI; all of them require that it has an equivalent the user can operate and perceive.

Spec / Signature Reference Table

The accessibility tools that pair with observers are mostly ARIA attributes and a few DOM APIs.

Step-by-Step Implementation

This walk-through makes an observer-driven results list accessible end to end: announced loads, a keyboard alternative, stable focus and a semantic structure.

Step 1: Render a live region once, up front

<div id="results-status" role="status" aria-live="polite" class="visually-hidden"></div>
<ul id="results" aria-busy="false" aria-describedby="results-status">…</ul>
<button id="load-more" type="button">Load more results</button>
<div id="sentinel" aria-hidden="true"></div>

A live region added at the same moment as its text is often not announced; it must already exist in the accessibility tree.

Step 2: Load from either the sentinel or the button

const status = document.getElementById('results-status')!;
const list = document.getElementById('results')!;
const button = document.getElementById('load-more') as HTMLButtonElement;
let loading = false;

async function loadNext(source: 'scroll' | 'button'): Promise<void> {
  if (loading) return;
  loading = true;
  list.setAttribute('aria-busy', 'true');
  const items = await fetchNextPage();
  const firstNew = appendItems(list, items);
  list.setAttribute('aria-busy', 'false');
  status.textContent = `${items.length} more results loaded, ${list.children.length} in total.`;
  if (source === 'button') firstNew?.focus({ preventScroll: false });  // take keyboard users to the new items
  loading = false;
}

new IntersectionObserver(([e]) => { if (e.isIntersecting) loadNext('scroll'); },
  { rootMargin: '400px' }).observe(document.getElementById('sentinel')!);
button.addEventListener('click', () => loadNext('button'));

declare function fetchNextPage(): Promise<unknown[]>;
declare function appendItems(list: HTMLElement, items: unknown[]): HTMLElement | null;

Step 3: Make new items focusable targets

appendItems should return the first new item's heading or link so focus has somewhere meaningful to go. Give headings tabindex="-1" if they are not already focusable; never move focus to a bare <li>.

Step 4: Keep the footer reachable

An infinite list that grows every time the keyboard user approaches the end makes the footer unreachable. Stop automatic loading after a few pages and rely on the button from then on, or disable the sentinel whenever focus is inside the list.

Threshold / Configuration Variants

The same feature can be tuned more or less aggressively, and the accessible choice usually sits at the conservative end.

Edge Cases & Gotchas

Focus-triggered loads. A keyboard user tabbing through a list scrolls each focused item into view. If the sentinel sits just after the last item, focusing the last item triggers a load, and new items appear after focus — fine. If the list is bidirectional and loads upward too, items inserted above focus shift the page; the browser keeps focus but screen magnifier users lose their place. See keeping keyboard focus stable.

Virtualised lists hide content from screen readers. A windowed virtual list only renders what is near the viewport; the rest does not exist in the DOM and cannot be found by screen-reader search. Provide aria-setsize and aria-posinset so users know how long the list is, and offer a non-virtualised view or search for long datasets.

Live regions and route changes. A live region inside a component that is unmounted and remounted on navigation is recreated, and the first announcement after remount is often lost. Keep one application-level status region outside routed content.

Lazy-loaded images and alt text. Swapping data-src to src is invisible to screen readers only if the alt was present from the start. An image that gains its alt on load is announced as an unlabelled graphic until then.

Reveal effects and screen readers. Content at opacity: 0 is still in the accessibility tree and is read aloud even though it is invisible. That is usually fine — it is the correct content — but content hidden with visibility: hidden until revealed is not read, so a screen reader that has not scrolled the page skips it.

Auditing an Existing Page

Most teams inherit observer-driven features rather than design them fresh. A structured audit finds the gaps quickly, and it is worth doing feature by feature rather than page by page, because the same component usually appears everywhere.

1. Inventory the observers. In the console, wrap the constructors before the page's scripts run (a DevTools snippet or a local override) and log each observe() target with a stack trace. The list tells you every place where the viewport, not the user, changes the page.

// DevTools snippet: run before page scripts via a local override.
const NativeIO = window.IntersectionObserver;
window.IntersectionObserver = class extends NativeIO {
  observe(target: Element): void {
    console.log('IO observe', target, new Error().stack?.split('\n')[2]);
    super.observe(target);
  }
};

2. Classify each one. For every observer, decide whether its effect is content (something appears that the user needs), state (something changes meaning, like an active link), presentation (motion, lazy pixels) or side effect (analytics, media playback). Content effects need an announcement or explicit control; state needs ARIA attributes; presentation needs reduced-motion and no-JS paths; side effects usually need nothing.

3. Exercise without scrolling. Use the keyboard alone, then a screen reader's virtual cursor alone, and note every piece of content you cannot reach or do not hear about. Those are the failures that matter.

4. Exercise without the observer. Block the script or force the feature-detection path to fail. Everything classified as content must still be reachable — via pagination, a button, or server-rendered markup.

Framework Integration Patterns

A shared announcer keeps live-region handling out of every component:

// announcer.ts — one polite region for the whole app
let region: HTMLElement | null = null;
let timer = 0;

export function announce(message: string, delayMs = 400): void {
  region ??= Object.assign(document.body.appendChild(document.createElement('div')), {
    className: 'visually-hidden',
  });
  region.setAttribute('role', 'status');
  clearTimeout(timer);
  // Debounce so a burst of loads produces one announcement; clear first so repeats are re-read.
  timer = window.setTimeout(() => {
    region!.textContent = '';
    requestAnimationFrame(() => { region!.textContent = message; });
  }, delayMs);
}

React components call announce() from an effect after a load resolves; Vue composables and Angular services wrap the same module. Creating the region lazily at first use still works because the debounce delay gives the accessibility tree time to register it before text arrives — but creating it at app start is more reliable in older screen readers.

Testing Accessibility in CI

Manual screen-reader testing catches the experience; automated tests stop regressions. The difficulty with observer-driven UI is that most accessibility scanners only examine the page as it is at load, before any observer has fired. The fix is to drive the page into its loaded states first, then scan.

import { test, expect } from '@playwright/test';
import AxeBuilder from '@axe-core/playwright';

test('results list stays accessible after two scroll-triggered loads', async ({ page }) => {
  await page.goto('/jobs');
  const status = page.getByRole('status');
  await expect(status).toBeAttached();                    // region exists up front

  for (let i = 0; i < 2; i++) {
    await page.locator('#sentinel').scrollIntoViewIfNeeded();
    await expect(page.locator('#results')).toHaveAttribute('aria-busy', 'false');
  }
  await expect(status).toContainText('more');             // a load was announced

  const results = await new AxeBuilder({ page }).include('#results').analyze();
  expect(results.violations).toEqual([]);

  // Keyboard path: the button loads without scrolling, and focus moves to new items.
  await page.getByRole('button', { name: /load more/i }).press('Enter');
  await expect(page.locator('#results :focus')).toBeVisible();
});

Three assertions carry most of the value: the live region exists before any load, aria-busy returns to false, and the keyboard control works without scrolling. Add a reduced-motion run (test.use({ reducedMotion: 'reduce' })) for pages with reveal effects, and a JavaScript-disabled run (test.use({ javaScriptEnabled: false })) to prove content is reachable without observers at all.

Debugging Checklist

• Navigate the whole feature with the keyboard only — can you reach every item, the load-more control and the footer?
• Use a screen reader (VoiceOver, NVDA or TalkBack) and read down the list with the virtual cursor — are new items announced or discoverable?
• Check the Accessibility pane in DevTools: live regions exist before they change, and aria-busy returns to false Check the Accessibility pane in DevTools: live regions exist before they change, and `aria-busy` returns to `false`.
• Emulate prefers-reduced-motion: reduce Emulate `prefers-reduced-motion: reduce` and confirm nothing moves.
• Zoom to 400% (WCAG 1.4.10 reflow) and confirm observer-driven features still work in the single-column layout.
• Run axe or Lighthouse accessibility audits after content loads, not only on first paint.

FAQ

Related

• Announcing Infinite Scroll Loads with aria-live — live regions done right
• Keeping Keyboard Focus Stable When Content Loads — focus and insertion order
• Accessible Lazy Images: Alt Text and Placeholders — images that are described before they load
• Making Scroll Spy Navigation Screen-Reader Friendly — conveying the active section
• Respecting prefers-reduced-motion in Scroll Reveals — motion safety

↑ Back to Implementation Patterns for Viewport & Resize Tracking