Accessibility in Web Development

Duration: 2 days

Target Audience

Developers, QA engineers, and technical roles (such as technical leads and product owners) who want to build inclusive, legally compliant digital products. No prior experience with accessibility is required — the workshop starts from the ground up and builds practical skills progressively.

Prerequisites

• Basic familiarity with HTML, CSS, and JavaScript
• Understanding of general web development concepts
• No prior accessibility experience required
• Bring a laptop with the following installed before the workshop:
  • A modern browser (Google Chrome or Microsoft Edge recommended)
  • Browser extensions: axe DevTools and WAVE Evaluation Tool
  • A screen reader: Windows — NVDA (free) or Narrator (built-in); macOS/iOS — VoiceOver (built-in); Android — TalkBack (built-in)
  • A code editor (e.g., Visual Studio Code)
  • Node.js (LTS version) — for CLI-based accessibility testing tools

Learning Objectives

By the end of this workshop, participants will be able to:

• Understand the core principles of digital accessibility and why they matter for users, businesses, and the law
• Identify and apply the relevant legal frameworks and standards (WCAG 2.1/2.2, European Accessibility Act 2025, BFSG, W-ADG)
• Recognize accessibility responsibilities across different roles in a product team
• Apply accessibility considerations early in the UX/UI design process
• Write accessible HTML, CSS, JavaScript, and ARIA code and resolve common accessibility issues
• Implement correct focus styling and focus management for keyboard and screen-reader users
• Use established accessible patterns for common UI components (navigation, dialogs, forms, tabs)
• Evaluate third-party UI libraries and frameworks for accessibility pitfalls
• Perform automated and manual accessibility testing and integrate checks into CI/CD pipelines

Agenda

Day 1 – Morning: Foundations and Legal Frameworks

1. Introduction to Digital Accessibility

• What accessibility means and who benefits — the disability spectrum and assistive technologies
• The business case: legal risk, market reach, and SEO benefits
• Overview of assistive technologies: screen readers, keyboard navigation, voice control, magnification

2. Legal Frameworks and Standards

• WCAG 2.1 and 2.2: structure, conformance levels (A, AA, AAA), and success criteria
• The European Accessibility Act (EAA) 2025 and its implications for software products
• German law: BFSG and W-ADG — scope, obligations, and deadlines
• POUR principles in depth: Perceivable, Operable, Understandable, Robust
• Role responsibilities: who owns accessibility in a product team?

Hands-on: Keyboard navigation exploration — navigate a real website using only the keyboard and identify failure points.

Day 1 – Afternoon: UX/UI Design and Accessibility

3. Accessibility in the Design Process

• Color contrast: WCAG ratios, tools, and common mistakes
• Typography, spacing, and touch target sizes for inclusive design
• Shifting left: embedding accessibility in wireframes and prototypes
• Accessible design patterns for common UI components: navigation, dialogs, forms, tabs, carousels

4. Design Review and Handoff

• Reviewing designs for accessibility before implementation
• Communicating accessibility requirements from design to development
• Using design tokens and component libraries accessibly

Hands-on: Color contrast lab — audit a provided design mockup, identify failures, and propose fixes.

Day 2 – Morning: Accessible Coding

5. Semantic HTML and ARIA

• Semantic HTML elements and landmark regions: <main>, <nav>, <header>, <aside>, headings
• When and how to use ARIA: roles, states, and properties
• ARIA authoring practices: the first rule of ARIA, live regions, aria-label vs. aria-labelledby
• Focus styling: visible focus indicators and :focus-visible
• Focus management: modals, single-page navigation, dynamic content

6. Accessible JavaScript Patterns

• Announcing dynamic content updates with ARIA live regions
• Keyboard interaction patterns: roving tabindex, composite widgets
• Building accessible custom components: dropdown menus, accordions, date pickers
• Common pitfalls: click-only handlers, div-based buttons, missing keyboard support

Hands-on: Live-coding session — fix a set of intentionally inaccessible UI components using semantic HTML, ARIA, and correct focus management.

Day 2 – Afternoon: Testing, Tools, and Best Practices

7. Automated Accessibility Testing

• Automated tools overview: axe DevTools, Lighthouse, pa11y, IBM Equal Access Checker
• What automated tools can and cannot catch (typically 30–40% of issues)
• Integrating axe or pa11y into CI/CD pipelines: GitHub Actions, Azure DevOps examples
• Linting for accessibility: eslint-plugin-jsx-a11y for React, similar tools for other frameworks

8. Manual Testing and Screen Readers

• Manual testing checklist: keyboard navigation, focus order, color contrast, form labels, error messages
• Screen reader basics: NVDA on Windows, VoiceOver on macOS — modes, virtual cursor, common shortcuts
• Testing dynamic content and single-page applications with screen readers
• Evaluating UI component libraries and frameworks for accessibility quality

9. Accessibility in the Development Workflow

• Accessibility acceptance criteria in user stories and definition of done
• Lightweight accessibility review process for pull requests
• Remediation strategies: prioritizing fixes by impact and effort
• Keeping up to date: WCAG updates, browser support changes, community resources

Hands-on: Full accessibility audit — run automated tools and manual screen reader tests on a provided sample application, document findings, and prioritize a remediation plan.

Hands-on Labs

• Navigate a real website using keyboard-only and identify WCAG failure points.
• Audit a design mockup for color contrast and touch target compliance; propose fixes.
• Fix a set of inaccessible HTML/CSS/JavaScript components in a live-coding session.
• Integrate pa11y into a CI/CD pipeline and configure failure thresholds.
• Perform a complete accessibility audit (automated + manual screen reader) on a sample web application and produce a prioritized issue list.

Outcomes

• Confident understanding of WCAG 2.1/2.2, EAA 2025, BFSG, and W-ADG requirements
• Able to write accessible HTML, CSS, JavaScript, and ARIA code from day one
• Skilled in using axe DevTools, NVDA, and VoiceOver for accessibility testing
• Capable of integrating automated accessibility checks into CI/CD pipelines
• Equipped to introduce accessibility practices into team workflows, design reviews, and definition of done