Accessibility · Component reference

Reading focus tools

A reading line, focus strip, larger pointer and visible keyboard focus.

Published and reviewed October 29, 2026 · Starlit’s implementation notes

Research and our take

Our recorded research compared reader preferences and accessibility tools across several projects. For this component, these observations informed Starlit’s approach:

OpenNagish: A broad grouped palette of text, navigation and reading controls. Our decision: Use its breadth as a discovery checklist, with explicit supported effects.
AccessKit toolbar: Feature cards, text controls and a pointer following reading strip. Our decision: Add a reading guide with a keyboard operated position control.

Starlit wrote the shared controller, scoped content adapters and component modules presented here. The referenced widgets are research sources, not browser dependencies. The component also draws on interface work in EvansWiki and PayCal.

Design reasoning

Help a reader keep their place without covering controls or intercepting input.

Start with the person’s task and the barrier they may encounter.
Offer a reading line or focus strip as an optional aid on long pages. Keep the guide within the selected content region.
Keep the ordinary content and action usable before adding enhancement.
Move the guide with its slider and a pointer. Activate a link beneath it, then dismiss it with Escape outside editable controls.

Usage pattern

Offer a reading line or focus strip as an optional aid on long pages. Keep the guide within the selected content region.

Impact and tradeoffs

A guide can reduce distraction but obscure context if too strong. Keep its position adjustable and dismissal easy.

Accessibility solutions

The guide ignores pointer events. Provide keyboard positioning, visible focus and a larger pointer fallback in forced colours.

Build accessible source content first. Personal preferences supplement semantic HTML, useful names, keyboard access and visible focus.

HTML

A concrete usage example. Host these assets on your own origin if you adapt the pattern. Read the source and credits before reuse.

<link rel="stylesheet" href="/open-ui/accessibility/shared/content.css">
<script type="module"
  src="/open-ui/accessibility/components/focus-tools/index.js"></script>

<article id="reading" data-sdou-a11y-content data-default-theme="dark">
  <div data-sdou-a11y-prose>
    <h2 id="begin">Begin with a clear purpose</h2>
    <p>Readable text and useful controls belong together.</p>
    <h2 id="details">Consider the details</h2>
    <p>The page should remain usable before any enhancement loads.</p>
  </div>
</article>
<sdou-focus-tools target="#reading"
  storage-key="example.focus-tools.v1"></sdou-focus-tools>

Open the HTML usage source

CSS

This is the component stylesheet used inside its Shadow DOM. The shared ui.css supplies its base controls and content.css adapts the reading region. An empty component stylesheet deliberately inherits the shared UI.

/* Reading focus tools. Component specific layout, shared controls live in shared/ui.css. */

JavaScript

This is the actual component module used by the live example. Imports, the base class and shared preferences are dependencies. Keep the component folder and shared folder in their relative positions.

import { A11yComponent, focus } from "../../shared/base.js?v=sdou20261029";
class FocusTools extends A11yComponent {
  static styles = new URL("./component.css?v=sdou20261029", import.meta.url).href;
  render() {
    this.mount(
      "Stay with the line.",
      "Choose a guide, then adjust its position with the slider or move a pointer over the text.",
      focus() +
        '<p class="hint">The guide covers only the reading area and never captures pointer or keyboard input. Escape closes the guide when no dialog is open.</p>',
    );
  }
}
customElements.define("sdou-focus-tools", FocusTools);

PHP integration

In your own application, PHP can render this HTML on the server. Here, the example is escaped text only. The library has no PHP runner or execution endpoint. The browser owns the interaction.

<?php
// Server render trusted structure and escape authored text.
// PHP does not implement or save these browser preferences.
declare(strict_types=1);
$title = 'A readable article';
$paragraph = 'Your authored content goes here.';
$e = static fn (string $value): string =>
    htmlspecialchars($value, ENT_QUOTES | ENT_SUBSTITUTE, 'UTF-8');
?>
<link rel="stylesheet" href="/open-ui/accessibility/shared/content.css">
<script type="module"
  src="/open-ui/accessibility/components/focus-tools/index.js"></script>
<article id="reading" data-sdou-a11y-content data-default-theme="dark">
  <div data-sdou-a11y-prose>
    <h2 id="begin"><?= $e($title) ?></h2>
    <p><?= $e($paragraph) ?></p>
  </div>
</article>
<sdou-focus-tools target="#reading"
  storage-key="example.focus-tools.v1"></sdou-focus-tools>

Open the PHP rendering source

API and dependencies

Element: sdou-focus-tools
target: A selector for the content region. Use a unique ID. Components sharing a target share its controller.
storage-key: A stable key for this project. Use the same key for controls targeting the same region. Preferences stay in browser storage when available.
Content: data-sdou-a11y-content marks the target; data-sdou-a11y-prose identifies reading copy. Use data-default-theme="dark" for a dark initial and reset preference.
Event: sdou:a11y-change is dispatched on the target with preferences, palette and reducedMotion in its detail.
Dependencies: Modern JavaScript modules, custom elements, Shadow DOM and native form controls. Dialog, speech, clipboard and fullscreen support depend on the feature and browser.

Read shared/base.js · Read the preference controller · Read the content adapter · Read the shared control styles

Testing and limitations

Move the guide with its slider and a pointer. Activate a link beneath it, then dismiss it with Escape outside editable controls.

The original library validation records automated rule checks, 320px reflow, enlarged text, text spacing, state persistence and relevant functional checks. Unresolved automated Shadow DOM reference checks are recorded separately from browser dialog checks. These historical results are not a new audit of every integration.

Production review still needs assistive technology, touch, zoom, custom styles and representative content. See our testing scope and known gaps. Report a barrier to Starlit.