> ## Content Index > Fetch the complete content index at: https://fieldnotes.tommytruong.com/llms.txt > Use this file to discover other available public pages before exploring further. # Browse by Topic - URL: https://fieldnotes.tommytruong.com/accessibility-field-guide/accessibility-topics/ - Published: 2026-07-20T02:38:35.000Z - Updated: 2026-07-21T03:16:45.000Z - Description: Browse Accessibility Field Guide topics by the kind of issue you are seeing in real project work. - Author: Tommy Truong - Tags: Guides, Accessibility, Accessibility Field Guide, Topics, Start Here Use this page when you have a practical accessibility question and do not want to start with WCAG numbers. The Accessibility Field Guide is organized around project moments: a request is getting shaped, a screen needs a quick check, a form is confusing, a vendor tool is coming in, or a component is behaving in a way people may not expect. Start with the issue you are seeing. Then follow the smallest useful path. ## If you are new to the guide Start here when you need the map before the details. - How to Use This Guide — choose the right entry point for the moment you are in. - Accessibility Glossary — look up common terms without starting from standards language. - Accessibility Skill Tree — see the kinds of accessibility judgment people build over time. - WCAG 2.1 A/AA Map — connect practical issues back to WCAG 2.1 A and AA. ## If the work is still being shaped Use this route before design, development, vendor selection, or review expectations have hardened. - Intake Accessibility Questions — ask better questions before accessibility risk becomes rework. - Intake Accessibility Questions Checklist — turn intake into a quick working prompt. - Accessibility Requirements Checklist — turn accessibility risks into requirements and acceptance criteria. - Review Readiness — understand what should be ready before formal review. - Review Readiness Checklist — check whether the work is ready to send forward. ## If you are checking a form or data-entry flow Use this route when someone has to enter, review, correct, or submit information. - Forms and Labels — check labels, instructions, required fields, grouping, and form structure. - Error Messages and Recovery — make errors easy to find, understand, and fix. - Form Review Checklist — run a practical pass through a form or flow. - Status Messages and Alerts — check confirmations, errors, alerts, and live updates. ## If keyboard or focus behavior might break the path Use this route when a screen has dialogs, menus, tabs, dynamic content, custom controls, or multi-step movement. - Keyboard-Only Navigation — check whether someone can complete the task without a mouse. - Focus Visible and Focus Order — check whether focus is visible and moves in a logical order. - QA Keyboard Check — use a no-mouse QA pass. - Modals and Dialogs — check focus movement, escape paths, and background interaction. - Status Messages and Alerts — check whether dynamic updates are announced when needed. ## If the issue is visual meaning, structure, or content Use this route when people need to understand a page from headings, text, images, color, tables, or layout. - Headings and Page Structure — make the page easier to scan and navigate. - Link Text and Button Labels — make control text clear out of context. - Alt Text Basics — decide what image meaning needs to be available as text. - Color Contrast — check whether text and interface elements have enough contrast. - Color-Only Meaning — avoid making color the only way to understand status or choice. - Tables and Data Displays — make data relationships easier to understand. ## If the issue is a control or component Use this route when the question is about what a control is, how it should behave, or whether ARIA is helping. - Native HTML First — start with the browser behavior that already exists. - Button vs Link — choose the control type based on what activation does. - Accessible Names — make sure controls have names people and assistive technology can use. - Name, Role, and Value — check whether a component exposes what it is and what state it is in. - ARIA Is Not Duct Tape — use ARIA to describe working behavior, not hide broken behavior. - Developer Component Checklist — run a practical component handoff/build check. - Accordions — check show/hide sections. - Combobox — check searchable/selectable inputs. - Tabs — check tabbed interfaces. ## If a vendor or third-party tool is part of the experience Use this route when a product, widget, platform, document generator, embedded service, or vendor workflow will affect users. - Vendor and Third-Party Accessibility Field Guide — understand the risk and ownership questions. - Vendor Accessibility Questions Checklist — ask what the evidence covers, what remains unknown, and who owns follow-through. Supporting notes: - A VPAT Is Not a Magic Shield - Accessibility Evidence Should Match the Thing You’re Shipping - Ask Vendors How Accessibility Works in Your Configuration ## If you need the checklist version Use Checklists and Job Aids when you want the working prompts instead of the explanatory pages. A good pattern is: 1. Read the topic page when the team needs context. 2. Use the checklist when the team needs a practical pass. 3. Use the WCAG map when the team needs the standard behind the issue. ## What to do next - If you are deciding where to start, read How to Use This Guide. - If you need a quick working aid, use Checklists and Job Aids. - If someone uses a term that is slowing the conversation down, use the Accessibility Glossary. - If you need the WCAG connection, use the WCAG 2.1 A/AA Map.