User Experience and Accessible Design

Completion evidence for this pathway is a task-based usability test, issue log, accessibility check and second prototype. Page count or time spent alone does not demonstrate competence.

The intended capstone is an accessible prototype for a real task tested with keyboard logic, screen-reader semantics and mobile layout. It should connect the lessons in one artefact and retain failed tests as evidence.

No week closes with reading alone. Use one session for concept and example, a second for practice, and a short third session for testing and explanation. Do not accelerate when a prerequisite is missing.

The pathway's distinctive question is: How can you prove that an interface is understandable, accessible and safe when errors occur? A first response may be a definition, but completion requires a task-based usability test, issue log, accessibility check and second prototype. If input, method, limits and review date are unclear, the result is not traceable even when it looks strong.

Start with two different activities among Captions, Sound and Multiple Alert Modes, Clarity and Visual Hierarchy in Interfaces, Empathy: Observe Instead of Assuming, Clear Error Messages and Recovery. In one, explain the concept in your own words; in the other, perform an application, measurement or user test. The two activities should not close with the same type of evidence. This distinction shows that User Experience and Accessible Design has been tested through different forms of production.

Later connect Project: Accessibility Audit of DorukVatansever.com, Colour, Contrast and Meaning Beyond Colour, Semantic Structure and Alternative Text, Consistency, Feedback and System Status to the capstone: An accessible prototype for a real task tested with keyboard logic, screen-reader semantics and mobile layout Keep failed tests as well as successful ones. For every error, record conditions, expected result, actual result, possible cause and the single change made.

Check these traps separately: Treating yourself as representative of every user; Using colour as the only information channel; Giving no recovery path in an error message; Replacing human testing with an automated score. Reading a trap is insufficient; find an example from your own work and state which evidence made the problem visible.

Return rule: When new user evidence arrives, the design changes, a new device is supported or an accessibility problem is reported. Do not delete the previous record; add a date, changed tool or source, new evidence and the next mini trial. Progress is therefore tracked through the quality of explanation, application and correction—not the number of pages completed.