Assistive Technologies and Design

Active learning works well here because students need to experience the gaps between intention and access. When they try tools themselves, they notice barriers that lectures alone cannot reveal. This builds empathy and technical insight at the same time.

• Year 8
• Technologies
• 4 activities
• 20 min–45 min

Learning Objectives

1. Compare the primary functions and use cases of at least three different assistive technologies, such as screen readers, voice control, and magnification software.
2. Analyze how specific interface design elements, like color contrast and button labeling, impact the usability of assistive technologies.
3. Design and prototype a simple interface component, such as a navigation button or a text input field, ensuring it adheres to accessibility guidelines for screen reader compatibility.
4. Evaluate the effectiveness of a given interface design in supporting users of specific assistive technologies.

Stations Rotation

⏱ 45 min·Small Groups

Stations Rotation: Assistive Tech Trials

Prepare four stations with laptops loaded: screen reader emulator, voice control simulator, magnification tool, and keyboard-only navigation. Small groups spend 8 minutes at each, testing sample websites and noting what works or fails. Groups report findings to the class.

Prepare & details

Differentiate between various assistive technologies and their functions.

Facilitation Tip: For the Station Rotation, set each station with a brief task card and a timer so students rotate with focus rather than rushing to finish.

Setup: Tables/desks arranged in 4-6 distinct stations around room

Materials: Station instruction cards, Different materials per station, Rotation timer

• Remember
• Understand
• Apply
• Analyze
• Self-Management
• Relationship Skills

Simulation Game

⏱ 30 min·Pairs

Pairs Prototype: Screen Reader Button

Pairs use HTML editors to create a button with proper labels and ARIA attributes. They test it with a free screen reader tool like NVDA simulator. Pairs swap prototypes for mutual testing and suggest fixes.

Prepare & details

Analyze how specific design choices can either enable or hinder assistive technology use.

Facilitation Tip: During the Pairs Prototype, ask students to script the exact sequence a screen reader would announce when a button is activated, forcing precision in labeling.

Setup: Flexible space for group stations

Materials: Role cards with goals/resources, Game currency or tokens, Round tracker

• Apply
• Analyze
• Evaluate
• Create
• Social Awareness
• Decision-Making

Simulation Game

⏱ 25 min·Whole Class

Whole Class Audit: Design Critique

Project student prototypes on screen. Class votes on accessibility using a checklist for voice control and screen reader compatibility. Discuss changes as a group and revise one example live.

Prepare & details

Construct an interface element that is designed to be compatible with a screen reader.

Facilitation Tip: In the Whole Class Audit, circulate with a checklist of WCAG criteria so students compare their findings against a shared standard.

Setup: Flexible space for group stations

Materials: Role cards with goals/resources, Game currency or tokens, Round tracker

• Apply
• Analyze
• Evaluate
• Create
• Social Awareness
• Decision-Making

Simulation Game

⏱ 20 min·Individual

Individual Mockup: Voice Menu Sketch

Students sketch a menu navigable by voice commands only. Use paper prototypes to simulate interactions. Share digitally for class feedback on command clarity.

Prepare & details

Differentiate between various assistive technologies and their functions.

Facilitation Tip: For the Individual Mockup, provide grid paper and colored pencils to emphasize layout as a critical accessibility factor, not just color contrast.

Setup: Flexible space for group stations

Materials: Role cards with goals/resources, Game currency or tokens, Round tracker

• Apply
• Analyze
• Evaluate
• Create
• Social Awareness
• Decision-Making

Teaching This Topic

Start with direct experience before theory. Research shows that empathy alone does not translate to better design; students need to test assumptions through structured simulations. Emphasize iteration: the first draft of an accessible feature is rarely the last. Avoid letting students default to visual fixes like bigger fonts without considering how screen readers interpret the same page. Use real-world examples to ground abstract concepts in concrete outcomes.

What to Expect

Successful learning looks like students moving from noticing problems in others’ designs to proposing fixes they can defend with evidence from their own trials. They should articulate specific features that support or hinder access, not just describe tools.

Watch Out for These Misconceptions

Common Misconception

During Station Rotation: Assistive Tech Trials, students may assume all tools feel the same for every user.

What to Teach Instead

During Station Rotation: Assistive Tech Trials, ask each pair to document one unique barrier they encountered and one moment of clarity, then share comparisons aloud to highlight differences in user needs.

Common Misconception

During Pairs Prototype: Screen Reader Button, students might think a button’s visual design matters most for accessibility.

What to Teach Instead

During Pairs Prototype: Screen Reader Button, have students swap scripts between pairs so they hear how the same button announces differently based on label choice, reinforcing that content matters more than appearance.

Common Misconception

During Whole Class Audit: Design Critique, students may believe adding color contrast fixes all accessibility issues.

What to Teach Instead

During Whole Class Audit: Design Critique, require students to test their fixes with a screen reader emulator, forcing them to address non-visual barriers they might have missed initially.

Assessment Ideas

Exit Ticket

After Station Rotation: Assistive Tech Trials, provide students with a brief reflection prompt: 'Name one tool you tested and describe one feature that surprised you about how it works, then explain why that feature matters for inclusive design.'

Discussion Prompt

After Pairs Prototype: Screen Reader Button, ask each pair to present their button’s script and one design choice they changed to improve clarity. Listen for whether they justify changes with user needs rather than aesthetics.

Quick Check

During Whole Class Audit: Design Critique, circulate and listen for students identifying at least two WCAG violations in the sample page, then ask them to share one fix they would implement immediately.

Extensions & Scaffolding

• Challenge: Ask students to research one WCAG 2.2 success criterion and design a single interactive element that meets it, then peer-test it with a screen reader.
• Scaffolding: Provide a partially completed HTML snippet with missing alt text and semantic tags; ask students to fill in only the accessibility gaps before testing.
• Deeper Exploration: Invite a guest speaker who uses assistive technologies daily to join the class and respond to student mockups in real time.

Key Vocabulary

Screen Reader	Software that reads aloud the text displayed on a computer screen, converting it into speech or braille output for visually impaired users.
Voice Control	Technology that allows users to operate a computer or device using spoken commands, bypassing the need for a mouse or keyboard.
Alt Text	Alternative text descriptions for images in web pages or documents, read by screen readers to convey visual information to users who cannot see the image.
Semantic HTML	Using HTML elements according to their intended meaning (e.g., using `<nav>` for navigation, `<button>` for buttons) to provide structure and meaning for assistive technologies.
Keyboard Navigation	The ability to access and operate all interactive elements of a website or application using only a keyboard, essential for users who cannot use a mouse.