Newer
Older
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
---
layout: assignment
published: true
title: Website/App Accessibility Report (Group)
description: Learn how to write about and remediate accessibility problems with websites and apps
code: hw2
assigned: Jan 10, 2023
due:
- Due on Jan 23, 2023, 5pm Pacific
- Two day grace period, Jan 25, 2023, 5pm Pacific
revised: Apr 11, 2023
---
* TOC
{: toc}
# Overview
The goal of this homework is to learn about basics of website accessibility and how to assess. In part 1, you: Learn how to use automated tools (and their limitations); Learn how to address the limitations of automated tools using accessibility tools; In part 2, you: Learn how to write up an assessment and prioritize what problems to fix; Practice identifying paths to fixing problems. You will also have the opportunity to practice UI image description.
Please note that *plain language* is *not* required (or expected) for this assignment.
## Competencies
This homework may contribute to your competency grade on
- Can articulate paths to addressing accessibility problems
- Accessible written document creation
- Image description
- Your participation grade, as a percentage of completeness (are all the required parts present)
## Length & Difficulty
Students in the past have reported that taken together, part 1 and part 2 of this assignment require a median of 20 hours (mode=6). 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]({{site.baseurl}}/academic-conduct.html). Some things that students have told us about this assignment:
- It helps to use the [UAR template](webegs/UAR_Template.doc) when filling out the UARS.
- It was very motivating to do this for a real client
# Details
For your report please do the following. To help you understand these requirements, here are is an example prior year's report that is a [good example](webegs/DigitalDefense.docx) of what you are aiming for (note that small details of requirements may have changed from year to year). Your report should be about 8 pages long, single spaced, with 12 point font. Your report should be accessible (including proper use of headings, ALT text, table markup and so on). If you directly quote anything when describing the issue (for example) include a footnote linking to your source, and put it in quotes.
## 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. Provide details on what 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 #. This is a good section of the report to divide and conquer in your group.
For each WCAG #
- summarize the issue of concern
- summarize the UAR(s) found if any
- 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 ar in HTML (e.g., H2 after and H1). Read [this for more guidance in how to do styles in Word.](https://support.microsoft.com/en-us/office/make-your-word-documents-accessible-to-people-with-disabilities-d9bf3683-87ac-47ea-b91a-78dcacb3c66d#bkmk_builtinheadings_win)
- 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](https://courses.cs.washington.edu/courses/csep590b/23wi/); Do not: click [here](https://courses.cs.washington.edu/courses/csep590b/23wi/) to learn more).
# Turnin
Turn in your report document. Note: **do not submit a PDF**. We expect your submission to be a Word or Google Doc.
Also turn in (individually) a description of what *you* contributed to the report. This will impact which competencies we grade you on. It is fine if more than one person works on the same thing, but describe how: For example, if one person made the reprot accessible, and a second person double checked it, tell us what role you played.