Assessment

Last revised date: 1/23/2026

Assigned:

  • Week 3 (Jan 19 2026) — Wednesday

Due:

  • Week 4 (Jan 26 2026) — Friday (was Wednesday) (UARS)
  • Week 5 (Feb 2 2026) — Monday (Writeup)

Overview

Learn about how to assess problems with websites and/or apps.

Required Competencies

When you turn in this homework, also turn in these competencies

Assignment Details

Your goal is to generate a range of UARs (Usability Aspect Reports) documenting accessibility concerns (and perhaps successes) with a website or app. You will use W3C guidelines for the site or app you are assessing.

A challenge that multiple students faced is summarizing the WCAG guidelines in their own words. Please be sure to do so, or to quote and reference WCAG guidelines according to our course policy on academic conduct. Some things that students have told us about this assignment:

  • It helps to use the UAR template when filling out the UARS.
  • It was very motivating to do this for a real client

The most relevant are probably WCAG 2.1 and How WCAG 2.0 Applies to Mobile (even websites may be used in mobile settings). If you are working on a mobile app, you should also review this PDF (specifically page 9): Epidemiology as a Framework for Large-Scale Mobile Application Accessibility Assessment.

0. (Group) Look over your assigned website and select 3 tasks

You will be assigned to one of eight websites that were submitted by external organizations for review. Please see Canvas for your specific assignment group. Note that this is not a group project, we are asking you to individually work on your assigned website this week. You will join forces next week with others in your section assigned to the same website, to write a report.

You will need to select what aspect of this site to test, you should have at least 3 different well defined tasks that you test. For example, you might select tasks such contacting support, and finding information about accessibility. Be sure to select tasks that are relevant to the website and any requests the submitter made.

1. (Group) Collect Data on accessibility problems using an automated accessibility checker

For each of these steps, you will record data about what you find so that you can complete the write up at the end.

You should run the website and/or app through an accessibility checker. The WebAim accessibility checker, WAVE, is a great choice for many sites. However, if the site requires that you log in, you may need an alternative. A great choice is the Axe Chrome plugin.

To install the Accessibility Scanner on android, search for it in the Play Store and install it on your device or emulator. The installation process will be the same for a physical phone or the emulator equipped with the Play Store. Follow the instructions on the Getting started with Google Accessibility Scanner page to get the scanner working on your device. Another option is to install the Android Accessibility Suite which contains both the Accessibility Scanner and TalkBack if it has not been installed before.

There is currently no IOS support for testing an application you do not have the source code for.

If you cannot find any problems, reach out to the staff for approval and we will help you identify a success category you can write up in a UAR that demonstrates how well accessibility is supported.

2. (Individual) Collect Data on accessibility problems using a screen reader

Try each task with it

Identify any problems with completing that task, different from the automated tool and other accessibility technology (next).

Record at least two problems, covering at least two different areas of POUR, in a problem report.

If you cannot find any problems, reach out to the staff for approval and we will help. In some cases, we may approve you to identify a success category you can write up in a UAR that demonstrates how well that AT is supported.

3. (Individual) Collect Data on accessibility using something other than a screen reader

The technology you choose should provide different information from a screen reader. For example, tabbing through the website will not provide different information than a screen reader, since a screen reader should not be used with a mouse. Using switch control, magnification, or voice input are good second choices.

Try each task with it

Identify any problems with completing that task

Record at least two problems, different from those found with the automated tool and screen reader.

If you cannot find any problems, reach out to the staff for approval and we will help. In some cases, we may approve you to identify a success category you can write up in a UAR that demonstrates how well that AT is supported.

4. (Individual) Record the data in a Usability Aspect Report

Record each group of similar issues you find using this Usability Aspect Report Template. You should generate a minimum of 6 4 UARS – two each for problems found with the automated tool, and each AT. Your 6 4 UARS should cover at least two different areas of POUR.

What goes in a UAR?:

  • Good or Bad Feature If your website as very accessible you may include UARS for particularly good features.
  • Source including your initials; the type of AT used; and a unique ID. For example, JM-SR-3 (which means, approximately, Jennifer Mankoff Screen Reader UAR # 3).
  • Name/Brief Description Provide a very brief name/summary
  • Evidence Specify the guideline violated and provide a screen shot with ALT text or other evidence of the violation.
  • Explanation Explain why this is a problem (or good aspect).
  • Severity Rank severity (with 4 being catastrophe)
  • Justification Justify your ranking in terms of frequency, impact and persistence
  • Relationship to other problems If this is related to/caused by/causes other problems you record, you can give their source number here

5. (Group) Write a report

Your report should have the following sections. [new] This is also your time to go through the group UARs and consolodate them. You should add UARs from the automated assessment at this stage as well.

1. Introduce what you did

Introduce the site or app, its purpose, and the task you assessed and state which accessibility tools, both automated and manual, you and others used in your assessment. It should include an overview table summarizing how you tested the site, that looks something like this.

Task Type (Web/Mobile/etc) Testing Method # UARS found Who Contributed
… … … …  

2. Provide an executive summary

Write an executive summary highlighting the biggest (most frequent, severe) problems, and your recommendations for fixing them. Keep this to 1-2 paragraphs.

You should also fill in the following overview table and put it in this section:

WCAG # # Severe problems # Moderate problems Minor problems
… … … …

3. Describe what you think needs to be done to fix the site or app

The remainder of your report should provide an overview, and detail, on the problems found, grouped by WCAG #.

For each WCAG #:

  • summarize the issue of concern (including listing the relevant UAR ids)
  • give an example of a typical case
  • provide details if there are any special cases
  • list (briefly) all the other places it happens

In addition, for each problem, or set of problems, you should discuss the remedy that is needed to address it. Be as concrete as you are able to be given the information available to you.

4. Make sure your report is accessible

We ask that you do four things to make the deliverable accessible. You should divide the report up and each of your group should specify which pages of the document (including the UARs in the appendix) you made accessible when you turn in the accessible document competency.

  • Use headers. In Microsoft Word these are built-in “styles” and in Google Docs you can see these under “Format -> Paragraph Styles.” Headers should be nested like they are in HTML (e.g., H2 after and H1). Read this for more guidance in how to do styles in Word.
  • Use proper color contrast. Note that some of the default styles in Microsoft Word do not have proper color contrast. You can right click on a style in the home bar and modify it.
  • Write alt text for all non-decorative photos.
  • Use meaningful hyperlink text (e.g., Do: check out my web page; Do not: click here to learn more).
  • Make good use of styles and lists, for sections, UARs, and so on
  • Make sure your tables are accessible.

Handin

Turn in a complete report, with all of your UARs in the appendix, ready to be shared back with your sponsor. Students should only put their names in the report if they want to get credit for authoring it, that is by choice.

The rest of the handin is broken up by competency

Note: The AT familiarity competency and accessible document competency are both individual.

Accessibility Assessment (rubric)

  • Your UARS (the number required depends on the assignment, but a minimum requirement is that they reflect multiple areas of POUR)
  • A link to the app or website your were testing if it is publicly available; and the names of the automated tool and ATs you used
  • Explain how your UARs cover at least two areas of POUR

Familiarity with a Range of Accessibility Technologies (rubric)

  • The video of you using the AT
  • Information about how each AT works, users, and strengths and weaknesses of the AT.
  • Information about what disabilities can benefit from it. For example, screen readers are not just used by blind people.
  • Any sources you used to answer these questions (first person accounts, research papers, etc). If you use Generative AI, you still need to check and cite relevant references.

Accessible Documents (rubric)

  • Your writeup (Microsoft word) or PowerPoint, or markdown (when required by the assignment). Note: do not submit a PDF. We expect your submission to be a Word or Google Doc.
  • A list of images and the ALT text you wrote for each of them
  • Which best practices are demonstrated in this document
  • A screen shot showing the accessibility checker results for your document

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.