Skip to content

Module. 9. Test Questions.md

Latest commit

 

History

History
332 lines (206 loc) · 8.98 KB

Module. 9. Test Questions.md

File metadata and controls

332 lines (206 loc) · 8.98 KB

📘 Module 9: Accessibility Best Practices

“Accessibility is not a feature; it is a fundamental human right.”

🎯 Module Objective

To empower documentation professionals to create inclusive, compliant, and usable technical content that supports individuals across the full spectrum of human diversity—including those with visual, auditory, motor, cognitive, and neurological differences.

Through deep technical insight and hands-on strategy, this module will teach you how to:

  • Embed accessibility from day one.
  • Master WCAG 2.2 and Section 508 standards.
  • Use screen readers and compliance tools.
  • Create documentation that works for all users.

🧠 Core Concepts

1. What is Accessibility in Documentation?

Accessibility in documentation refers to the practice of designing, writing, and structuring content so that all users—including people with disabilities—can access, understand, and navigate it effectively.

  • Visually impaired users may rely on screen readers.
  • Motor-impaired users may navigate only by keyboard.
  • Users with cognitive conditions may benefit from simplified structure and clarity.

🔍 Quote Insight: “Accessible documentation removes barriers. It's not an extra step—it’s part of the design.”

2. Why Accessibility Matters

  • 🟢 Inclusivity – Ensures equal access to all users regardless of ability.

  • ⚖️ Compliance – Adheres to legal requirements:

    • WCAG 2.2
    • Section 508 (USA)
    • ADA (Americans with Disabilities Act)
    • EN 301 549 (EU)

  • 🔎 SEO – Accessible content is better structured for indexing.

  • 👓 Usability – Enhances experience for all users, including those without disabilities.

🔑 Inclusive Design Principles

Accessibility principles follow the POUR model:

Principle Key Idea Example
Perceivable Information must be presented in ways users can perceive Alt text, color contrast, text size
Operable Interface must be navigable via different inputs Keyboard navigation, logical tab order
Understandable Language must be clear and predictable Simple sentence structures, glossaries
Robust Content must work with current and future tech Semantic HTML, ARIA roles

🔧 Tools, Techniques & Standards

3. Screen Reader Compatibility

  • Use semantic HTML: <nav>, <section>, <article>

  • Include ARIA landmarks: aria-label, aria-labelledby

  • Tools for testing:

    • NVDA (Windows)
    • VoiceOver (macOS)
    • JAWS

✅ Checklist:

  • Hierarchical headings: H1 → H6
  • All images use descriptive alt text
  • Forms have associated <label> or aria-label

4. Accessible Visuals

  • Maintain contrast ratio (WCAG 2.2 minimum: 4.5:1 for text)
  • Never convey information with color alone
  • Add alternative text for complex visuals like charts

🛠 Tools:

5. Clear Language Techniques

  • Sentences ≤ 20 words

  • Use active voice

  • Avoid:

    • Idioms: “Hit the ground running”
    • Metaphors: “Boiling point”
    • Acronyms (unless defined)

📘 Follow:

📏 Compliance Frameworks

6. WCAG 2.2 Principles Deep Dive

Principle Focus
Perceivable Text alternatives, adaptable layout
Operable Keyboard accessibility, navigation order
Understandable Language clarity, input assistance
Robust Compatibility with AT tools

7. Section 508 Overview

Applies to all U.S. federal institutions:

  • Software and web content must be accessible.
  • Legal requirements enforce adherence.

8. EN 301 549 (Europe)

Mandates ICT products (hardware, software, web services) to be accessible in EU government and public service projects.

🧭 Application in Documentation Workflows

9. Plan for Accessibility from Day One

  • Add accessibility checklists to Jira/Trello tasks.
  • Build accessibility gates into peer reviews and QA.
  • Define requirements early in product specs or sprint docs.

10. Accessible Documentation Templates

# Page Title

## Purpose  
Concise description of what the document is for.

## Audience  
Specify who the documentation is intended for.

## Prerequisites  
Mention what users need to know beforehand.

## Visuals  
![Alt text: A diagram showing the user flow from login to checkout.]

## Table: Key Commands
| Command | Description |
|---------|-------------|
| `Ctrl + S` | Saves the current file |

11. Testing & Review Process

🧪 Manual Testing:

  • Screen reader walkthrough (VoiceOver/NVDA)
  • Navigate the doc keyboard-only
  • Focus ring visibility for all interactive elements

🤖 Automated Tools:

  • Axe
  • WAVE
  • Google Lighthouse

📚 Real-World Scenarios

🧩 Scenario 1: Improper Heading Nesting

❌ Problem: H1 followed by H4 and H5 — screen readers confused. ✅ Solution: Apply logical hierarchy: H1 → H2 → H3.

🧩 Scenario 2: Graph With No Alt Text

❌ Problem: Pie chart has no text summary or alt. ✅ Solution: Add alt or accompanying textual breakdown.

🧩 Scenario 3: Complex Terms Without Definition

❌ Problem: Usage of “containerized orchestration tools” with no context. ✅ Solution: Tooltip with description + glossary.

🧠 Brain Teasers (Advanced Level)

  1. Why must keyboard navigation replicate all interactive mouse functionality?

    Consider cases where mouse usage is impossible due to motor disabilities.

  2. Is a video tutorial with only background music compliant?

    Analyze under WCAG Perceivable and Understandable principles.

  3. True or False: Color-coded status indicators (red/yellow/green) are always accessible.

    Defend your answer with an accessibility strategy.

  4. Explain semantic HTML to a junior dev using a screen reader analogy.

    Build empathy through metaphor.

  5. What accessibility risks are introduced by infinite scroll components?

📝 Advanced Assignments

🎯 Assignment 1: Audit and Remediate

  1. Choose a documentation page in your portfolio.

  2. Run it through WAVE or Axe.

  3. Fix 3 major accessibility issues.

  4. Submit:

    • Screenshot of test results before & after
    • Description of what you changed and why

🎯 Assignment 2: Build a Compliant Doc from Scratch

Using the template below, write a 500-word technical doc that meets WCAG 2.2.

# Page Title

## Purpose

## Audience

## Visual

![Alt text: Describe the image]

## Glossary
- **API**: Application Programming Interface

✅ Must Include:

  • Alt text
  • Clear language
  • At least 3 semantic headings
  • Table with scope attribute

🎯 Assignment 3: Accessibility Case Study Presentation

Prepare a 3-slide presentation answering:

  • What accessibility challenges did you face in a real or imagined project?
  • How did you resolve them?
  • What tools helped you assess compliance?

🧪 Bonus Challenge: Accessibility Detective

You are assigned to QA a documentation site that “looks perfect.” But a screen reader user flags it as unusable.

You find:

  • No aria-labels in form fields
  • Modal dialogs can't be exited via keyboard
  • Font sizes are styled in pixels (px)

🎯 List all WCAG 2.2 principles violated 🎯 Recommend fixes with exact code snippets

💼 Instructor Notes

  • Use screen reader demos (e.g., NVDA) in class.
  • Assign peer reviews focused solely on accessibility.
  • Simulate disabilities using Chrome extensions (like “No Mouse”).
  • Compare inaccessible vs. accessible versions of the same doc.

📈 Outcome

By completing this module, learners will:

✅ Design and write fully inclusive documentation ✅ Identify accessibility flaws early in the writing lifecycle ✅ Apply WCAG, Section 508, and EN 301 549 practically ✅ Use screen readers and automated tools for audits ✅ Embed accessibility into every doc workflow

🏁 Want to Practice More?

Try these repos: