diff --git a/assignments/index.md b/assignments/index.md
index 17d54bd5ac1252546946091894e7dfd594e2b3e4..c5f997c7b91605e30127a7bb7f66cc31247c1508 100644
--- a/assignments/index.md
+++ b/assignments/index.md
@@ -20,7 +20,8 @@ questions or run into issue, please contact the course staff.
| Link to Assignment | Turn in Link | Due Date |
|--------------------------------------------------------------------------------------------|-------------------------------------------------------------------------------|----------|
| HW1: [Disability Justice]({{site.baseurl}}/assignments/disabilityjustice.html) | [EdStem discussion post](https://edstem.org/us/courses/31170/discussion/new/) | 1/9 |
-| HW2: [Web/App Access Assessment]({{site.baseurl}}/assignments/website.html) | [Canvas Link](https://canvas.uw.edu/courses/1619674/assignments/7840155) | 1/23 |
+| HW2a: [Web/App Access UARS]({{site.baseurl}}/assignments/website.html) | [Canvas Link](https://canvas.uw.edu/courses/1619674/assignments/7840155) | 1/17 |
+| HW2b: [Web/App Access Report]({{site.baseurl}}/assignments/website-report.html) | [Canvas Link](https://canvas.uw.edu/courses/1619674/assignments/7840155) | 1/23 |
| HW3: [Finding AT around us]({{site.baseurl}}/assignments/finding-accessibility.html) | [Canvas Link](https://canvas.uw.edu/courses/1628215/assignments/8008424) | 1/31 |
| HW4: [2nd Wave Accessibility Writeup]({{site.baseurl}}/assignments/technology-review.html) | [Canvas Link](https://canvas.uw.edu/courses/1628215/assignments/8081613) | 2/7 |
| HW5: [Plain Language]({{site.baseurl}}/assignments/plain-language.html) | | Last week of class |
diff --git a/assignments/webegs/DDUARS.docx b/assignments/webegs/DDUARS.docx
new file mode 100644
index 0000000000000000000000000000000000000000..33a93c81561a55f8a3a97a599efd3af6219e0ca2
Binary files /dev/null and b/assignments/webegs/DDUARS.docx differ
diff --git a/assignments/example-webaccess-report.docx b/assignments/webegs/DigitalDefense.docx
similarity index 79%
rename from assignments/example-webaccess-report.docx
rename to assignments/webegs/DigitalDefense.docx
index f63ec03b1cf37e2d2bcdab172f2a2937e981cb9c..19228f312e90d0e2555d41093fe2d120be100e39 100644
Binary files a/assignments/example-webaccess-report.docx and b/assignments/webegs/DigitalDefense.docx differ
diff --git a/assignments/UAR_Template.doc b/assignments/webegs/UAR_Template.doc
similarity index 64%
rename from assignments/UAR_Template.doc
rename to assignments/webegs/UAR_Template.doc
index 0e293f8fb62dd08f6543f324bb64a0a5432be100..fbae642d077d7c777765dd99b4a3f1b16de8e254 100644
Binary files a/assignments/UAR_Template.doc and b/assignments/webegs/UAR_Template.doc differ
diff --git a/assignments/webegs/VolunteerMeet UARS.docx b/assignments/webegs/VolunteerMeet UARS.docx
new file mode 100644
index 0000000000000000000000000000000000000000..8e3f815430073aab449d10e73778c62ecd9dd4ad
Binary files /dev/null and b/assignments/webegs/VolunteerMeet UARS.docx differ
diff --git a/assignments/webegs/VolunteerMeet.docx b/assignments/webegs/VolunteerMeet.docx
new file mode 100644
index 0000000000000000000000000000000000000000..90d5de5091404a7a8aa830e6b7b228df9221e99f
Binary files /dev/null and b/assignments/webegs/VolunteerMeet.docx differ
diff --git a/assignments/webegs/~$R_Template.doc b/assignments/webegs/~$R_Template.doc
new file mode 100644
index 0000000000000000000000000000000000000000..027393691040f83a620117c95b472da6d80bef15
Binary files /dev/null and b/assignments/webegs/~$R_Template.doc differ
diff --git a/assignments/website-report.md b/assignments/website-report.md
new file mode 100644
index 0000000000000000000000000000000000000000..a3d57a65db1eb7786f7070a4bd74a7e391c868bd
--- /dev/null
+++ b/assignments/website-report.md
@@ -0,0 +1,82 @@
+---
+layout: assignment
+published: true
+
+title: Website/App Accessibility Report (Group)
+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 will 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.md). 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.
diff --git a/assignments/website.md b/assignments/website.md
index c1d197a2614c6181e5a3cdffce98843d9073292c..afb49d0e5217ff4bd28fa5e7761cd7247b83b6be 100644
--- a/assignments/website.md
+++ b/assignments/website.md
@@ -2,39 +2,45 @@
layout: assignment
published: true
-title: Website/App Accessibility Assessment
+title: Website/App Accessibility UARS (Individual)
code: hw2
assigned: Jan 10, 2023
due:
- UARS--Due before class on 1/17
- - Report--Due on Jan 23, 2023, 5pm Pacific
- - Two day grace period, Jan 25, 2023, 5pm Pacific
+ - No grace period--These will be discussed in class
-revised: Jan 3, 2023
+revised: April 11, 2023
---
* TOC
{: toc}
-# Learning Goals
-The goal of this homework is to learn about basics of website accessibility and how to assess; Learn how to use automated tools (and their limitations); Learn how to address the limitations of automated tools using accessibility tools; 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.
+# 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.
-## 0. Pick a website and/or app and two tasks
-You may submit your top three choices for website/app from listing below and include at most one of your own on the [Ed Discussion thread for selection](https://edstem.org/us/courses/31170/discussion/2351217) for this assignment. Our goal is to have *at least four students** working independently on each website. Note that there is a *task* associated with each website/app (and if you pick your own, you should also have a task in mind).
-
-{% details Possible websites/apps %}
-In the past, website have been sponsored by CREATE partners and community members. Student reports have been received by them with great gratitude, generating comments such as "This is fantastic" and "What an amazing and helpful report!" with plans to implement the recommendatinos.
+## Competencies
+This homework will contribute to your competency grade on
+- Can apply web/app accessibility rules to identify problems, including
+ - 1 whether content is perceivable
+ - 2 whether content is operable
+ - 3 whether content is understandable
+ - 4 whether content is robust
+ <!-- - 5 the meaning of conformance -->
+- Can use an accessibility checker to assess whether a web page or app is accessible
+- Can use an accessibility technology to find web page or app accessibility problems that are not found with an automated accessibility checker
+- 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)
-- [VolunteerMeet Techies For Reproductive Justice](https://ddf.volunteermeet.org/): VolunteerMeet is a tool for abortion access and reproductive justice groups to use to recruit and vet volunteers. VolunteerMeet is used by several large organizations, and we want to make sure we are not limiting the participation of people with disabilities. **Focus**: The application process.
-- [Digital Defense Fund](https://digitaldefensefund.org/): Our website has a large amount of (free!) material about how to access abortion and other reproductive health care safely in today's criminalized environment. We have resources about digital security, staying safe online, and tech-enabled advocacy, among many other topics - all of which are incredibly important to all of us, but perhaps especially to people may be more vulnerable to surveillance because of their disabilities. **Focus**: Two sections of our site in particular: Learn & Media
-- [PAVE](https://wapave.org/): With our goal of continual improvement, we would like to always test the website periodically to make sure we are making sure it is accessible to everyone. **Focus**: Accessibility and ease of use
-- [CREATE](https://create.uw.edu/): CREATE's website should already be pretty accessible, but we haven't had any outside testers look at it. Help us find th egaps and problems! **Focus**: Finding out about funding
-- Other: We are happy to take submissions for other websites that you might want to focus on. If you do this, you must recruit *at least one* other student in the class (preferably three others) who will (independently) look at the same website
-{% enddetails %}
+## 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.md). 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
-### Guidelines
-You will use [W3C guidelines](https://www.w3.org/WAI/standards-guidelines/) for the site or app you are assessing.
+# Details
+Your goal is to generate a range of UARs documenting accessibility concerns (and perhaps successes) with a website or app. You will use [W3C guidelines](https://www.w3.org/WAI/standards-guidelines/) for the site or app you are assessing.
The most relevant are probably [WCAG
2.1](https://www.w3.org/WAI/standards-guidelines/wcag/glance/) and
@@ -46,11 +52,23 @@ mobile app, you should also review this PDF (which is numbered page
Accessibility
Assessment](https://xiaoyizhang.me/assets/Paper/ASSETS_2017_Epidemiology.pdf).
+## 0. Pick a website and/or app and two tasks
+You may submit your top three choices for website/app from listing below and include at most one of your own on the [Ed Discussion thread for selection](https://edstem.org/us/courses/31170/discussion/2351217) for this assignment. Our goal is to have *at least four students** working independently on each website. Note that there is a *task* associated with each website/app (and if you pick your own, you should also have a task in mind).
+
+{% details Possible websites/apps %}
+In the past, website have been sponsored by CREATE partners and community members. Student reports have been received by them with great gratitude, generating comments such as "This is fantastic" and "What an amazing and helpful report!" with plans to implement the recommendatinos.
+
+- [VolunteerMeet Techies For Reproductive Justice](https://ddf.volunteermeet.org/): VolunteerMeet is a tool for abortion access and reproductive justice groups to use to recruit and vet volunteers. VolunteerMeet is used by several large organizations, and we want to make sure we are not limiting the participation of people with disabilities. **Focus**: The application process.
+- [Digital Defense Fund](https://digitaldefensefund.org/): Our website has a large amount of (free!) material about how to access abortion and other reproductive health care safely in today's criminalized environment. We have resources about digital security, staying safe online, and tech-enabled advocacy, among many other topics - all of which are incredibly important to all of us, but perhaps especially to people may be more vulnerable to surveillance because of their disabilities. **Focus**: Two sections of our site in particular: Learn & Media
+- [PAVE](https://wapave.org/): With our goal of continual improvement, we would like to always test the website periodically to make sure we are making sure it is accessible to everyone. **Focus**: Accessibility and ease of use
+- [CREATE](https://create.uw.edu/): CREATE's website should already be pretty accessible, but we haven't had any outside testers look at it. Help us find th egaps and problems! **Focus**: Finding out about funding
+- Other: We are happy to take submissions for other websites that you might want to focus on. If you do this, you must recruit *at least one* other student in the class (preferably three others) who will (independently) look at the same website
+{% enddetails %}
-## 1. Collect Data on the accessibility problems with that website and/or app
+
+## 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.
-### Run an accessibility checker
You should run the website and/or app through an accessibility checker. The WebAim accessibility checker, [WAVE](https://wave.webaim.org/), 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 [Chrome plugin Axe](https://chrome.google.com/webstore/detail/axe-devtools-web-accessib/lhdoppojpmngadmnindnejefpokejbdd?hl=en-US).
To install the Accessibility Scanner on android, search for it in the
@@ -63,86 +81,34 @@ page to get the scanner working on your device. Another option is to install the
For iOS, you should install the Accessibility Inspector, which is freely available through the App Store. More details on [testing for accessibility in iOS.](https://developer.apple.com/library/archive/documentation/Accessibility/Conceptual/AccessibilityMacOSX/OSXAXTestingApps.html)
-### Test it yourself
-Use *multiple approaches*, including at a minimum **a screen reader** and **switch input** to assess the website
+## 2. Collect Date on accessibility problemsusing TWO DIFFERENT accessibility technologies
+Use *multiple approaches*, including at a minimum **a screen reader** and **magnification** to assess the website
and/or app, and your ability to complete the assigned task using
accessibility tools. You may also use other accessibility tools if you
-feel there are things that does not address.
+feel there are things that does not address, such as speech based input, or switch input.
Here are some resources that may help you in gaining comfort with these accessibility technologies
-- Switch control intro: [Switch Control overview](https://www.youtube.com/watch?v=GQKEE9nI1lk)
+- [Zoomtext and other magnification in use](https://www.youtube.com/watch?v=4ZRVDgeMpXc) and [Setting up windows for zooming](https://www.youtube.com/watch?v=TQhUCnMhDZE)
- [Screen reading intro](https://axesslab.com/what-is-a-screen-reader/)
+- Switch control intro: [Switch Control overview](https://www.youtube.com/watch?v=GQKEE9nI1lk)
+- Advanced voice based input: [voice programming](https://www.youtube.com/watch?v=YKuRkGkf5HU)
-### Record the data in a *Usability Aspect Report*
-Short (1 page max) report for each group of similar issues you find using this [Usability Aspect Report Template](UAR_Template.doc)
+## 3. Record the data in a *Usability Aspect Report*
+Record each group of similar issues you find using this [Usability Aspect Report Template](webegs/UAR_Template.doc). Here is a [sample](webegs/DDUARS.docx) that a prior student has kindly shared with us for you to look at. Make sure that your UARs are accessible
-For example, consider this view of the the WebAIM automated accessibility checker. The red mountain with the X indicates that it is missing an image description. To write this up, you would record the
+Some key things to make note of:
- **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 such as JM-SR-3 (which means, approximately, Jennifer Mankoff Screen Reader UAR # 3)
-- **Name** as "Missing Image ALT Text";
-- **Evidence** Guideline violated: 1.1 ([Text Alternatives](https://www.w3.org/WAI/WCAG22/Understanding/text-alternatives));
- - **Screen Shot** as the image and URL ([lib.washington.edu](https://www.lib.washington.edu/));
-
-- **Explanation** A screen reader won't be able to describe this image
-- **Severity** 2. **Justification** This is debatable, but frequency is low (it only occurs once on this site. If you are writing up all missing image alt text as a group, you might increase your estimate of frequency, but this site doesn't appear to have a lot of undescribed images); impact is low (it is possible to determine the purpose of this image by either clicking on it to see what it links to, or inferring some things from the external link and image file name (both unpleasant alternatives for a screen reader user); and persistence is high (it's not going to go away).
-- **Possible Solution** This is easy to solve, describe the image and all text in it. "December Update in a white circle surrounded by wintry trees. Around it are the words 'Hours Update', 'New Exhibits', 'Workshops' and 'Finals Help'"
-- **Relationship to other problems** Since we only have one example UAR here we don't have much to say, but this could mention for example other areas of the website which are missing labels such as form entries or buttons.
+- **Name/Brief Description** Provide a very brief name/summary
+- **Evidence** Specify the guideline violated and provide a screen shot with ALT text or other evidenc.
+- **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
# Turnin
-(1) You will turn in your UARs on the problems you found **in one week** on Ed, including images *with ALT text*. Be sure to include at least on UAR from a switch, screen reader and automated tool. If your website is *very* accessible you may include a "good UAR" highlighting someting good you found, to demonstrate that you tested with a variety of tools.
-
-(2) In two weeks you will write up 5 page report documenting problems **that you and others found** on your website and suggesting solutions. Here are is an example prior year's report that is a [good example](example-webaccess-report.docx) of what you are aiming for (note that small details of requirements may have changed from year to year).
-
-Your report should be accessible (including proper use of headings, ALT text, table markup and so on) and have the following structure:
-- The first page should 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 that looks something like this.
-
-| Task | Type (Web/Mobile/etc) | Testing Method | # UARS found | Who Contributed |
-|:-----|:----------------------|:---------------|:-------------|-----------------|
-| ... | ... | ... | ... | |
-|:-----|:----------------------|:---------------|:-------------|-----------------|
-
-- The first page should also have an executive summary of the biggest (most frequent, severe) problems, and your recommendations for fixing them. Keep this to 1-2 paragraphs, you will provide more detail in the following pages.
-- The next section of the report should provide an overview, and detail, on the problems found.
- - You should start with an overview table that looks something like this.
-
-| WCAG # | # Severe problems | # Moderate problems | Minor problems |
-|:-------|:------------------|:--------------------|:---------------|
-| ... | ... | ... | ... |
-|:-------|:------------------|:--------------------|:---------------|
-
-- Next, there should be a subsection 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
- - Finally discuss the remedy that is needed
+Submit your UARS as an attachment to the appropriate [discussion]({site.discussion})
-If you directly quote anything when describing the issue (for example) include a footnote linking to your source, and put it in quotes.
-(3) You should also turn in a separate document with all of the UARS used in your report (both yours and those of any students who looked at the same website). Clearly label which are yours when you do this.
-## Accessibility of Deliverable
-We expect your submission to be a Word or Google Doc. 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).
-
-Note: **do not submit a PDF**.
-
-# Competencies
-This homework will contribute to your competency grade on
-- Can apply web/app accessibility rules to identify problems, including
- - 1 whether content is perceivable
- - 2 whether content is operable
- - 3 whether content is understandable
- - 4 whether content is robust
- <!-- - 5 the meaning of conformance -->
-- Can use an accessibility checker to assess whether a web page or app is accessible
-- Can use an accessibility technology to find web page or app accessibility problems that are not found with an automated accessibility checker
-- 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)