Inclusive Design, Accessibility & Plain Language

Field	Value
Type	Agent Reference
Source	~/.copilot/agents/_refs/senior-ux/inclusive-design.md
Description	Not specified

Source Content

Inclusive Design, Accessibility & Plain Language

Accessibility is not a feature. It’s not a phase. It’s a constraint that applies to every decision from minute one. Designing for accessibility improves the experience for everyone.

Plain Language & Content Design

Words are interface elements. Confusing labels, jargon-filled instructions, and walls of text are design failures — just as real as a broken button.

Follow the principles established by the Federal Plain Language Guidelines (plainlanguage.gov) and the Plain Writing Act of 2010. These aren’t just government rules. They’re proven communication principles.

Write for your audience, not for yourself.

• Use everyday words. Say “use” instead of “utilize.” Say “help” instead of “facilitate.” Say “start” instead of “initiate.” Say “end” instead of “terminate.” Say “about” instead of “approximately.”
• Write at a 6th to 8th grade reading level for general audiences. This is not dumbing down. This is respecting your reader’s time.
• Use active voice. “You can save your file” not “Your file can be saved.”
• Address the user directly. “You” is the most powerful word in UI copy.
• Write short sentences. Aim for 15–20 words per sentence.
• Limit paragraphs to one idea and no more than 5 sentences.
• Use the present tense. “This saves your file” not “This will save your file.”
• Avoid double negatives. “You can continue” not “You cannot not proceed.”

Readability & Scannability

People scan before they read. Most never read at all. Design every screen for scanning first, reading second.

Headings are signposts. Make headings descriptive enough that someone scanning only headings understands the content structure. Headings must make sense when read out of context. Screen reader users often navigate by headings alone.

Front-load key information. Put the most important word or concept at the beginning of every heading, label, sentence, and paragraph. Users read the first 2–3 words and decide whether to continue.

Break up long content. No wall of text. Use descriptive subheadings, short paragraphs, and bulleted lists to chunk information. Following the guidance from Practical UI: break large pieces of information into multiple smaller ones so people can understand them faster.

Use progressive disclosure for content too. Show the summary first. Let users expand for details. Don’t overwhelm people with everything at once.

Microcopy matters. Button labels, form hints, error messages, tooltips, empty states — these tiny pieces of text do enormous work. Treat them with the same care as headlines.

Labels, Instructions & Microcopy

• Labels use the user’s vocabulary, never system or developer jargon
• Button labels describe the action: “Save changes” not “Submit.” “Create account” not “Register.” “Delete project” not “Confirm.”
• Error messages are specific and actionable: “Enter an email address like <name@example.com>” not “Invalid input”
• Empty states tell users what to do next, not just “Nothing here.” Show a clear path forward: “You haven’t added any projects yet. Create your first project to get started.”
• Confirmation messages tell the user what happened: “Your changes are saved” not “Success”
• Loading messages tell the user what’s happening: “Loading your dashboard” not just a spinner
• Instructions are unnecessary in a well-designed interface — but available if needed via tooltips or help links

WCAG 2.1 AA Requirements (Minimum)

• Color contrast: 4.5:1 for normal text, 3:1 for large text and UI components
• Touch targets: Minimum 44×44px on mobile. 48×48px recommended.
• Focus indicators: Visible, high-contrast outlines on all interactive elements. Never remove default focus styles without replacing them.
• Text resizing: UI works correctly at 200% zoom without horizontal scrolling or content overlap
• No information by color alone: Every color-coded element also has an icon, pattern, or text label

Keyboard & Screen Reader Support

• All functionality is accessible via keyboard alone
• Tab order matches visual layout — logical, predictable, left-to-right and top-to-bottom
• ARIA labels on all interactive elements that lack visible text
• Semantic HTML structure: proper heading levels (h1 → h2 → h3, never skip), landmarks (nav, main, aside, footer), lists, tables
• Skip navigation links on content-heavy pages
• Live regions (aria-live) for dynamic content updates
• Form inputs always have associated labels (not just placeholders)

Inclusive Design Patterns

• Support both light and dark modes via prefers-color-scheme
• Respect prefers-reduced-motion — disable or reduce animations for users who request it
• Provide text alternatives for all images, video, and audio
• Design for one-handed mobile use (critical actions in the thumb zone)
• Consider low-bandwidth and offline states — show useful content even when connections are slow
• Support screen magnification — no clipping, overlapping, or hidden content at high zoom levels
• Test with actual assistive technology (screen readers, switch controls, voice control) — not just automated tools

Implementation Notes

When generating code:

• Use semantic HTML elements: nav, main, section, article, aside, header, footer, figure, figcaption, details, summary
• Prefer CSS Grid and Flexbox for layout — never use tables for layout
• Use CSS custom properties (variables) for all design tokens: colors, spacing, typography, border-radius, shadows
• Include prefers-color-scheme media query for dark mode support
• Include prefers-reduced-motion media query to respect motion preferences
• Mobile-first CSS with min-width breakpoints
• Include :focus-visible styles for keyboard users (not just :focus)
• Use relative units (rem, em) for text sizing — never fixed px for font sizes
• Set max-width on text containers to enforce 40–80 character line length
• All images have alt text. Decorative images use alt=""
• All form inputs have associated label elements
• Test with axe-core or similar automated accessibility tools as a starting point, then verify manually

References

Plain Language

• Federal Plain Language Guidelines (plainlanguage.gov) — The gold standard for clear communication
• Practical UI by Adham Dannaway — Chapter 6: Copywriting
• Don’t Make Me Think by Steve Krug — Mindless, unambiguous choices
• Content Design by Sarah Richards — Write for the user’s need
• Nicely Said by Nicole Fenton & Kate Kiefer Lee — Voice and tone
• Writing Is Designing by Michael Metts & Andy Welfle — Words as design

Accessibility

• WCAG 2.1 — Web Content Accessibility Guidelines (W3C)
• Section 508 — US federal accessibility requirements
• Inclusive Design Principles (inclusivedesignprinciples.org) — Henny Swan, Ian Pouncey, Heydon Pickering, Léonie Watson
• A Web for Everyone by Sarah Horton & Whitney Quesenbery
• Accessibility for Everyone by Laura Kalbag
• Inclusive Components by Heydon Pickering