How to Make a Dense RPG Character Sheet Easier to Navigate With a Screen Reader

Before changing the layout, list the questions you ask most often during play. For example: “What do I add to this check?”, “Which actions can I take?”, “What does this feature do?”, and “How many uses remain?” These questions are a practical index: they tell you what information must be easy to reach and what can sit in a less frequently used reference section.

Group information by task rather than by the visual shape of a printed sheet. A character’s key numbers might be spread across several boxes, but a screen reader user may have to read through unrelated text to assemble them. Put the pieces needed for one routine together, or provide a short, clearly labeled quick-reference section that points to fuller explanations below.

Keep the game’s rules and your character’s actual values intact. Reorganizing a sheet changes where information lives, not what a feature, statistic, or resource means.

Create one clear document title, then use descriptive section headings such as “Checks and defenses,” “Actions in a turn,” “Features and limits,” “Equipment,” and “Session notes.” Make headings reflect what follows, so a player can decide where to jump without reading every paragraph. W3C guidance explains that correctly marked headings help screen-reader users navigate and understand a document’s outline; changing font size or boldness alone does not provide that structure. W3C guidance on writing for web accessibility

Use built-in heading styles in a word processor or the appropriate heading controls in your digital tool, rather than merely formatting ordinary text to look like a heading. Keep the hierarchy logical: a main section should be a top-level heading, and a subsection should sit beneath it. Avoid choosing heading levels only for their visual size. The heading list should read like a compact map of the character sheet.

Give headings enough detail to distinguish similar sections. “Abilities” may be vague if it includes both checks and special abilities; “Ability checks” and “Character features” make clearer destinations. W3C recommends descriptive headings and labels, and notes that correct markup lets assistive technology expose them for navigation. W3C on headings and labels

Order the sections around the session’s rhythm. A compact opening section might contain the character name, commonly used modifiers, defenses, movement or other routinely checked values, and the resource most often updated. Follow it with action options and feature descriptions, then less frequently consulted details such as background, longer equipment notes, or campaign history.

Keep the opening section concise enough to be useful. It should answer common questions, not reproduce the entire sheet before the player reaches the rest. If the same number appears in a quick reference and a full section, decide which is authoritative and update both when the character changes. A short maintenance note—“Update the quick reference when this value changes”—can prevent drift.

Use labels that say what a number means. “Bonus: +5” is more useful than “+5” on its own; “Uses remaining: 2” is clearer than a bare “2.” If a resource changes in play, provide a consistent way to find both its current value and its limit, such as “Focus: 2 of 3 uses remaining.” Do not rely on color, position, borders, or symbols alone to communicate the distinction: those cues may not carry over when the content is read aloud. WebAIM recommends logical document structure and clear text rather than color alone. WebAIM’s introduction to web accessibility

For each rule or feature, put the name first, then explain what it lets the character do, when it applies, what it costs or requires, and any limit or duration. Keep these details together so the player does not have to search elsewhere to finish a decision. A consistent pattern can help: “Feature name. Use when… Choose… Cost… Limit… Effect ends when…” Adapt the fields to the game; omit ones that do not apply.

Separate options into real lists when they form a set, such as actions, spells, prepared items, or conditions. Give each item a distinct name and a short explanation. Avoid simulated columns made from tabs, repeated spaces, or decorative separators: their visual arrangement may not make the relationships clear when read linearly. If an item has a longer rules explanation, keep a brief action summary near the list and provide a descriptive heading for the full entry.

For images of a character sheet or handwritten notes, add text that conveys any information the image contains, or transcribe that information into the document. A decorative portrait does not need to carry gameplay data. W3C advises that text alternatives should communicate an image’s information or function, while purely decorative images can be left without descriptive alternative text. W3C guidance on writing for web accessibility

Use a table only when the information depends on row-and-column relationships, such as an inventory with item, quantity, and notes. Give columns specific names, keep the table simple, and use actual header cells in tools that support them. W3C explains that screen readers can announce header information while users move through a correctly marked-up data table; visually aligned text or tabs do not preserve those relationships. W3C technique for table markup

Many character options are easier to follow as headings and lists than as a wide table. A spell or feature table with long descriptions can force repeated movement across columns and make it harder to keep the current item in context. If a table is necessary, limit its columns to information that is genuinely comparable and avoid merged cells or multiple levels of headings when a simpler structure will work.

For a fillable sheet, make sure each control has a meaningful label and can be reached and used in a logical order. A checkbox should be identified by the option it controls, not by location or an unexplained mark. WebAIM notes that form controls need programmatically associated labels. The exact setup varies by app, so check the controls in the tool where the sheet will actually be used. WebAIM’s introduction to web accessibility

A short “At a glance” section can make common actions faster, while the complete feature text remains available under its own heading. For example, the quick section might say “Second Wind — regain health; once per rest,” while the full feature entry explains the game’s exact timing and amount. Label summaries as summaries, and do not let them replace a condition or exception that could change how an action works.

This two-layer approach is most useful when the character has many options. It gives the player a brief route for routine checks and a fuller route for unfamiliar situations. If the rules are still being learned, keep the wording close to the official character options or the group’s agreed notes, and retain any conditions that affect use.

Open the sheet in the same app and screen reader you expect to use at the table. First inspect the heading list: do the section names form a useful outline, and can you jump directly to checks, actions, and features? Then navigate using the app’s normal reading and control methods to find a frequently used modifier, an action’s cost or limit, and a resource you need to update. Screen reader commands vary, so follow the guidance for your specific screen reader rather than assuming one universal shortcut.

Listen for what is missing as well as what is repeated. A heading may look prominent but fail to appear in the heading list; a number may be announced without a label; or a table may read across cells without making their relationship clear. Correct the document structure or wording, then repeat the same routes. If a PDF or exported copy is part of your routine, check that version too: accessibility can change during export, and an editable source does not guarantee that the exported file kept its structure. WebAIM advises making non-HTML documents accessible and notes that tagged PDFs can expose structure to screen readers. WebAIM on accessible documents

Ask the player who will use the sheet which routes matter and whether the revised structure works for them. Preferences, tools, and familiarity differ; a checklist can find structural problems, but it cannot decide someone else’s preferred organization. Keep the source sheet easy to update, and revisit the quick-reference details whenever the character changes.

• Writing for Web Accessibility – Tips for Getting Started

• Understanding Success Criterion 2.4.6: Headings and Labels

• H51: Using table markup to present tabular information

• Introduction to Web Accessibility