(Week: 6) G: Milestone 2: Prototype & Architecture

Last revised date: 10/22/2026

View / submit on Canvas

Overview

Build a prototype, document its architecture, and start on accessibility. Your goal is to be ready for user testing and accessibility auditing.

When you turn in this homework you will be assessed on these competencies: Accessible Implementation. Accessible Communication.

Assignment Details

Key: pink is Canvas, blue is your project repo, green is your project public site.

Flowchart of the Milestone 2 tasks. A text version follows the image.

Text version of this diagram
  • Build a prototype for all 3 tasks (can be hifi). Commit to relevant repo.
  • Start making your prototype accessible.
  • Update documentation (public)
    • Document each task in public/system.html.
    • Architecture / Feasibility (public/architecture.html).
    • Prototype Accessibility (public/vpat.html).
  • Make your public website accessible (check with WAVE).
  • Update the Log.md
    • Log your contributions in LOG.md#build (repo).
  • Tag repo & submit to Canvas

Before you start

Your project overview, first-person research paragraphs, design concept and storyboard should already be on your project site from Milestone 0 and Milestone 1. As you receive feedback on these, or as your project evolves, you are welcome to update them. Likewise, if you received feedback on earlier milestones, you can address it now. We’ll review any changes and update any relevant competency grades when we review your Milestone 2 submission.

Milestone 2 requires you to edit the following:

Build your prototype

Build a prototype that covers all 3 of your planned tasks (Your project may choose lofi or hifi, or mix them, based on what makes the most sense).

Commit any prototype code to GitLab or submit it as a pull request to the open source repository you are modifying. Omit API keys, but document what’s required to configure them. If your prototype is made of images of lofi mockups, commit those to GitLab.

Document your prototype (system.html)

In the Overview of System section of the System page, document each task with an image of your prototype (a photo of a lofi mockup, a sketch, or a screenshot). Include alt text for each image.

Start on accessibility (vpat.html)

We’re going to focus only on things that will translate to your final product. To do so, you will start the VPAT table that you will complete over the next two milestones. Add rows as needed for this. We will start with three things from the WCAG beginners’ guide. See Accessibility Tools for tools that may help you check these.

  1. Text contrast (1.4.3). Any accessibility checker should flag issues for you.
  2. Non-text contrast (1.4.11). Basically the same as text contrast, but for buttons, icons and so on.
  3. ALT text for non-text content (1.1.1). ALT text is much easier to write if you do it as you go. Everything you build that uses images should either mark them as decorative, or provide ALT text.

Add this table to the VPAT page of your project site:

Criteria Severity Conformance Level Brief Explanation
1.4.3 (Contrast) skip    
1.4.11 (Non-text Contrast) skip    
1.1.1 (Non-text Content) skip    

Fill in the Conformance Level (Supports, Partially Supports, or Does Not Support) and use Brief Explanation to explain what you found and how. You can skip severity for now. If you don’t have time to fill in all of the alt text, or check all the contrast, that is OK – just say “Partially Supports” or “Does Not Support” and explain. The goal of a VPAT is to be accurate, not perfect.

You can provide more information below your table (since explanations in a table are hard).

Document your architecture (architecture.html)

On the Architecture / Implementation page include:

  • Architecture diagram (example on a11yhood.org)
  • Feasibility assessment (address relevant issues across concepts discussed in lecture including Technical, Financial, Socially appropriate, Operational, and Timeline.

Think of this as a planning exercise – describe the architecture you plan to build, and your assessment of how feasible it is (addressing one or more of the items discussed in class). Be sure to account for accessibility in both, however. This includes allocating time for making things accessible, and designing the architecture to support accessibility (such as making ALT text easy to enter and maintain when images are uploaded, or choosing a toolkit that makes use of native web components over one that uses mostly DIVs.).

Make your public website accessible

Check that your project website is following accessibility best practices. If you use markdown cleanly, this should mainly require:

  • ALT text on images, diagrams and videos
  • Proper header order
  • Contrast (if you changed the style at all)

However you should check it thoroughly using the WAVE automated accessibility tester

Contributions

Log your individual contributions in LOG.md#build.

Submitting for grading

At the deadline,

  1. tag your repo (git tag milestone-2 && git push origin milestone-2)
  2. submit the tagged link to your README in Canvas (e.g. .../-/blob/milestone-2/README.md)

Completeness

Checklist (is your assignment complete)

  • A lofi (or hifi) prototype for all 3 tasks is committed to your repo
  • system.html has an image of each task, with alt text
  • vpat.html has the VPAT table started for your prototype
  • architecture.html has an architecture diagram and a feasibility assessment
  • public website passes a WAVE check
  • LOG.md#build has an entry from every team member

See Canvas

Back to top

The University of Washington acknowledges the Coast Salish peoples of this land, the land which touches the shared waters of all tribes and bands within the Suquamish, Tulalip and Muckleshoot nations. This site is maintained by J. Mankoff.