Assessment

Last revised date: 12/9/2025

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. 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. 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.

2. Collect Data on accessibility problems using TWO DIFFERENT accessibility technologies

First you will need to decide which two accessibility technologies you will use. The technologies you choose should provide different information from each other. 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. Most people select a screen reader, and magnification or voice input. If you already use one of these technologies on a regular basis, please check in with the course staff about best choices.

Use multiple approaches, including at a minimum a screen reader, and one other AT to assess the accessibility of the website and/or app, and your ability to complete the assigned task using accessibility tools. The second AT you choose should provide different information than what a screen reader would. For example, using switch control or voice input are good second choices. However, using the tab key to navigate the website as the second AT is NOT considered for competency.

Once you have picked your technologies, collect data on accessibility problems using the two accessibility technologies. You should find at least two new problem with each AT, that you did not already find with the automated tool. 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 that AT is supported.

3. 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 UARS – two each for problems found with the automated tool, and each AT. Your 6 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

4. Write a report

Your report should have the following sections:

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:

  • 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).

Handin

The handin is broken up by competency

Accessibility Assesssment (rubric)

  • At least six UARS (two each from automated testing and your two different ATs).
  • 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)

  • 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. 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 or PowerPoint
  • A screen shot showing the accessibility checker results for your document or PowerPoint

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.