# data[].attributes.body
Students work in teams to complete a condensed 3-hour design sprint. Teams receive a real-world design problem and must go through all stages: empathize, define, ideate, prototype, and test. Each phase is time-boxed, forcing quick decision-making and creative problem-solving. End with team presentations and peer feedback.

# data[].attributes.body
Students create detailed user personas for a specific design project. They must include demographics, goals, pain points, and behavioral patterns. Students conduct mini-interviews with real potential users and incorporate findings into their personas. Present and justify personas to the class for feedback.

# data[].attributes.body
AAAAA

# data[].attributes.body
Students choose a well-designed product or interface and break down its design decisions. They must identify and document: target audience, problem being solved, design principles used, successful elements, and areas for improvement. Create a presentation explaining their analysis.

# data[].attributes.body
Using only basic materials (paper, cardboard, tape, etc.), students have 45 minutes to create a prototype solving a given design challenge. Focus on quick iteration and functionality over aesthetics. After time's up, teams test each other's prototypes and provide feedback.

# data[].attributes.body
Students create a comprehensive design system for a fictional brand. Include color palettes, typography, component library, usage guidelines, and design principles. Present to class acting as if pitching to a client. Other students play role of stakeholders asking questions.

# data[].attributes.body
Teams conduct an accessibility audit of a popular website or app. Create checklist covering WCAG guidelines, test with screen readers, check color contrast, keyboard navigation, etc. Document findings and propose solutions. Share insights with class.

# data[].attributes.attachment_link.readable_text
The following is NOT the Web Content Accessibility Guidelines (WCAG) 2. It is a checklist that presents our recommendations for implementing accessibility principles and techniques for those seeking WCAG conformance. The language used here significantly simplifies and condenses the official WCAG 2.1 specification and supporting materials to make it easier to implement and verify for web pages.
Guidelines for using this checklist:

This checklist should not be referenced in policies or in policy adoption. While this is a useful resource for technical implementation of WCAG, it is not a comprehensive policy checklist. Official WCAG documentation provides much better mechanisms for implementing accessibility into policy or law.

WCAG covers accessibility of all web content and is not technology specific. The language of this checklist has been simplified and targeted to identify most common techniques and failures for HTML and mobile content. It is, therefore, fairly limited and subject to technology changes, whereas WCAG is much less so.

This checklist contains WebAIM's interpretation of WCAG guidelines and success criteria and our own recommended techniques for satisfying those success criteria. The first column of the table below links to the official WCAG 2.1 success criteria.

Success criteria added in WCAG 2.1 are marked as such and have a light green background.

A PDF version of this checklist is also available

Perceivable
Web content is made available to the senses - sight, hearing, and/or touch

Guideline 1.1
Text Alternatives: Provide text alternatives for any non-text content

Success Criteria

WebAIM's Recommendations

Images, form image buttons, and image map hot spots have appropriate, equivalent alternative text.

Images that do not convey content, are decorative, or contain content that is already conveyed in text are given empty alternative text (alt="") or implemented as CSS backgrounds. All linked images have descriptive alternative text.

Equivalent alternatives to complex images are provided in context or on a separate linked page.

Form buttons have a descriptive value.

Form inputs have associated text labels.

Embedded multimedia is identified via accessible text.

Frames and iframes are appropriately titled.

Guideline 1.2
Time-based Media: Provide alternatives for time-based media

NOTE: If the audio or video is designated as an alternative to web content (e.g., an audio or sign language version of a web page, for example), then the web content itself serves as the alternative.

Guideline 1.4
Distinguishable: Make it easier for users to see and hear content including separating foreground from background

Success Criteria

WebAIM's Recommendations

Color is not used as the sole method of conveying content or distinguishing visual elements.

Color alone is not used to distinguish links from surrounding text unless the contrast ratio between the link and the surrounding text is at least 3:1 and an additional distinction (e.g., it becomes underlined) is provided when the link is hovered over and receives focus.

Blocks of text over one sentence in length:

Are no more than 80 characters wide.

Are NOT fully justified (aligned to both the left and the right margins).

Have adequate line spacing (at least 1/2 the height of the text) and paragraph spacing (1.5 times line spacing).

Have a specified foreground and background color. These can be applied to specific elements or to the entire page using CSS (and thus inherited by all other elements).

Do NOT require horizontal scrolling when the text size is doubled.

No loss of content or functionality occurs and horizontal scrolling is avoided when content is presented at a width of 320 pixels.
This requires responsive design for most web sites. This is best tested by setting the browser window to 1280 pixels wide and then zooming the page content to 400%.

Content that requires horizontal scrolling, such as data tables, complex images (such as maps and charts), toolbars, etc. are exempted.

When additional content is presented on hover or keyboard focus:

The newly revealed content can be dismissed (generally via the Esc key) without moving the pointer or keyboard focus, unless the content presents an input error or does not obscure or interfere with other page content.

The pointer can be moved to the new content without the content disappearing.

The new content must remain visible until the pointer or keyboard focus is moved away from the triggering control, the new content is dismissed, or the new content is no longer relevant.

Operable
Interface forms, controls, and navigation are operable

Guideline 2.3
Seizures and Physical Reactions: Do not design content in a way that is known to cause seizures or physical reactions.

Success Criteria

WebAIM's Recommendations

Guideline 2.4
Navigable: Provide ways to help users navigate, find content, and determine where they are.

Success Criteria

WebAIM's Recommendations

A link is provided to skip navigation and other page elements that are repeated across web pages.

A proper heading structure and/or identification of page regions/landmarks may be considered a sufficient technique. Because navigating by headings or regions is not supported in most browsers, WebAIM recommends a "skip" link (in addition to headings and regions) to best support sighted keyboard users.

Understandable
Information and the operation of user interface must be understandable.

Robust
Content must be robust enough that it can be interpreted by a wide variety of user agents, including assistive technologies

Guideline 4.1
Compatible: Maximize compatibility with current and future user agents, including assistive technologies

Success Criteria

WebAIM's Recommendations

This checklist is provided as a resource to help implement Web Content Accessibility Guidelines (WCAG) 2.1 (W3C Recommendation 5 June 2018), which is Copyright © 2017-2018 W3C®.

# data[].attributes.attachment_link.description
The following is NOT the Web Content Accessibility Guidelines (WCAG) 2. It is a checklist that presents our recommendations for implementing accessibility principles and techniques for those seeking WCAG conformance. The language used here significantly simplifies and condenses the official WCAG 2.1 specification and supporting materials to make it easier to implement and verify for web pages.

# data[].attributes.body
Class divides into teams to debate ethical design dilemmas. Topics might include dark patterns, data privacy, addictive design, or algorithmic bias. Teams research cases, prepare arguments, and engage in structured debate. Conclude with class discussion on establishing ethical design principles.

# data[].attributes.body
Students map the complete journey of a service experience (e.g., visiting a doctor, ordering food delivery). Document touchpoints, pain points, emotions, and opportunities for improvement. Create visual journey maps and present improvement proposals to class.

# data[].attributes.body
Students conduct detailed competitive analysis of designs in a specific sector (e.g., food delivery apps, streaming services). Create comparison matrix of features, design patterns, and UX elements. Present findings and recommend best practices based on analysis.

# data[].attributes.body
Students pair up to review each other's design portfolios or project work. Provide structured feedback form covering visual design, problem-solving, presentation, and storytelling. Each student gives and receives detailed feedback, then implements improvements.

# data[].attributes.body
Teams tackle a design challenge with sustainability as the primary constraint. Must consider materials, lifecycle, environmental impact, and circular economy principles. Research existing sustainable design solutions and create proposals that prioritize environmental responsibility.