---
layout: presentation
title: Assessment --Week 3--
description: Assessment of how Accessible Apps and Websites are
class: middle, center, inverse
---
background-image: url(img/people.png)
.left-column50[
# Week 3: Assessment
{{site.classnum}}, {{site.quarter}}
]
---
name: normal
layout: true
class:
---
# Important Reminder
## This is an important reminder
## Make sure zoom is running and recording!!!
---
# Announcements
- Assignments posted on Ed
- Use your own words in UARs, or quote and reference -- a reminder that citational justice is deeply connected to concepts in this class
- Remember, skills aren't meant to be perfect on the first try, many of them take practice. That's ok!
---
[//]: # (Outline Slide)
# Learning Goals for Today
- **What are the current accessibility standards** (1 and 2)
- How to make media accessible (Diagrams; GUIs; videos)
- How do we use automated tools
---
# Introduction to Accessibility Standards
In this class we will structure our learning around the Web Accessibility Initiative ([WAI](http://www.w3.org/wai/)), a service of the World Wide Web Consortium (W3C)
- Makes recommendations for Web authors, browsers and servers: **Web Content Accessibility Guidelines (WCAG)**
- WCAG is an ongoing project
- There is no *official* equivalent for non-web programming, <BR> but WCAG can easily be applied to apps as well
- Lots of ways to learn WCAG <BR> (e.g. this [certificate program](https://de.torontomu.ca/wa/); this [textbook](https://pressbooks.library.torontomu.ca/pwaa/); and [WebAIM](https://webaim.org))
???
We could spend a whole quarter on this... but we're going to limit it to one or two weeks
"live" (regularly being worked on and updated, with input from the disability community).
---
# The [POUR](https://webaim.org/articles/pour/) standard
- Perceivable: Web content is made available to the senses - sight, hearing, and/or touch
- Operable: Interface forms, controls, and navigation are operable
- Understandable: Information and the operation of user interface must be understandable.
- Robust: Content must be robust enough that it can be interpreted by a wide variety of user agents, including assistive technologies
.footnote[Note: There is a 5th thing, Conformance, which we are not covering]
???
This is appropriate for *all* disabilities -- don't think access is only an issue for blind and low vision (BLV) people
Obviously there is some overlap between these, and they build on each other
---
# Three levels of compliance
*Some* users with disabilities can access and use web content (A)
*Removal of significant barriers* overall to accessing content (AA)
*Enhancements to web accessibility* for more users with disabilities (AAA)
Most apps and websites today only meet *part* of (A) level compliance!
---
# POUR: Perceivable: Guidelines 1.1-1.4
.left-column[
## Guideline 1.1
Text Alternatives: Provide *electronic text* alternatives for any non-text content
]
.right-column[
<iframe src="https://embed.polleverywhere.com/free_text_polls/6vnlXnjXmIytsl4RGkEfW?controls=none&short_poll=true" width="800px" height="600px"></iframe>
]
???
Why non text?
- Can be rendered visually, auditorially, tactilely, or by any combination.
- Can also be easily enlarged
---
# Different Types of Non-Text Content
Read up on some of these links when you are faced with specific description needs
.left-column50[
- [Decorative and branding](https://dl.acm.org/doi/pdf/10.1145/3308558.3313605)
- Formatting and text styling
- Images as links
- [Diagrams](https://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=9028522&casa_token=zZw_rYBgu1AAAAAA:eozpbJ-vvMZjQNt8p6WU91X4uFumPs-yVuMn4PTPRjyMhtsVrprdIEe1JfYOCUdv8SFP_TGd9s965Q&tag=1)
- [Visualizations](https://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=9555469)
- [Memes](https://dl.acm.org/doi/10.1145/3308561.3353792)
- [GUIS](https://dl.acm.org/doi/10.1145/3411764.3445040)
]
.right-column50[
- Animations/Videos (we'll talk more about this later today)
- AR/VR ([Accessibility, Disabilities, and VR](https://educatorsinvr.com/2019/05/31/accessibility-disabilities-and-virtual-reality-solutions/))
- [Comparison of IoS and Android Rich Interactions](https://dl.acm.org/doi/pdf/10.1145/2851613.2851680?casa_token=dOz4huS0TUkAAAAA:zv0PjZk3-T8Bb4X2SfNpdZFuqO2u9v1jpWn5fq0hKZ0se6t5g0oMKLfrAmhlyufcw_3AuJ-ABZ2yWQ)
- ...
]
???
All of these require different strategies to describe them well.
Read up on some of these links when you are faced with specific description needs
---
# Small Group Activity
Break into small groups and show each other the inaccessible diagram, screenshot, or other non-photograph you found. Pick one and work on a description for it. Do more if you have time [post]({{site.discussion}}/454543)
---
# Diagrams (1 of 2)
.left-column40[
]
.right-column60[
When direct exploration isn't possible, consider descriptions that are *language based*
]
---
# Diagrams (2 of 2)
<tt>
stateDiagram-v2 <BR>
[*] --> Still<BR>
Still --> [*]<BR>
Still --> Moving<BR>
Moving --> Still<BR>
Moving --> Crash<BR>
Crash --> [*]<BR>
</tt>
---
# Math standard for accessibility is MathML
Math has a hierarchy just like other systems (i.e. fractions, parantheses)
Can support with MathML
Can generate MathML using pandoc; MS Word; etc
Capturing an image of an equation and describing it much worse for screen reader users
---
# Image Description: GUIs
.left-column40[
]
.right-column60[
[Investigating Visual Semantic Understanding of Blind and Low-Vision Technology Users](https://dl.acm.org/doi/abs/10.1145/3411764.3445040)
- Visual attributes that convey aesthetics and usability of user interfaces.
- Desktop and smartphone screen readers provide control type and other semantic information excluding any visual semantics.
- Smartphones allow for some degree of spatial exploration.
]
---
# Study
How do BLV technology users understand and access visual semantics?
???
Interviews;
Screen reader tasks;
Reconstruction
---
# Results
.left-column50[
.quote[
The way I think about this is on the top is my email, to the right is my phone number. Below that [is] essentially a 2 by 2 kind of thing, which has my social profile.
]
]
.right-column50[
Participants were aware of the overall structure of *phone apps*
- They developed this understanding using screen readers
- Associated size and location and function
- Layouts were understood in terms of absolute, relative, and corner positions
]
---
# My description of the leftmost GUI
---
# My description of the leftmost GUI
- App has two tabs at top center: Delivery and Pickup.
- Below is a seach bar with address and time menu and an advertisement for The Burger Joint (25% of screen) with a details button
- Next is a scrolling set of tabs for Pickup; Grocery; Prescription; Top Sites; the rest is not visible off screen
- The bottom 30% of the screen shows the title Hidden Gems (Up and coming spots you'd like) with a list of restaurants. Each row in the list shows an image, restaurant name, rating, and more. The list requires 2D scrolling to see everything. The top two are visible: Tsuki Ramen and Chocolate Co.
???
This is very hard to describe without knowing what is accessible; and whether the user is more interested in content or layout.
---
# Describing GUIs is rarely necessary
GUI description best supported dynamically through exploration. Critical needs for this
- Accessibility information available for interface
- Touch screen phone interaction techniques
Don't describe GUIs, explore them.
---
.left-column40[
]
.right-column60[
## Developer Responsibility
Expose GUI structure
Provide good ALT text
- What is a good name for the "Like" Button?
- Enable the user to understand the name of the control they have navigated to, what type of control it is, what value it has, what state it has.
]
---
.left-column40[
]
.right-column60[
## Proper ALT text
Screen reader will read out name, role, and state. Don't repeat these.
Good alt text: Name ("Like")
API knows: Role ("Button")
API knows: State ("Not selected")
]
---
.left-column40[
]
.right-column60[
## Exception: Your UARs
My alt text for the like button (assuming it's the subject of my UAR, slide or etc)
A picture of facebook with a like button visible at bottom left (a thumbs up followed by the word like)
]
---
# POUR: Perceivable: Guidelines 1.1-1.4
.left-column[
## Guideline 1.1
Text Alternatives: Provide *electronic text* alternatives for any non-text content
]
.right-column[
Make these perceivable
- Image
- Controls, Input
- Time-Based Media
- Visual Test or Exercise
- Sensory Experience
- CAPTCHA
Make this ignorable
- Decoration, Formatting, Invisible
]
---
# POUR: Perceivable: Guidelines 1.1-1.4
.left-column50[
Make these perceivable
- Controls, Input
- Time-Based Media
- Visual Test or Exercise
- Sensory Experience
- CAPTCHA
]
.right-column50[
Example Best Practices:
- Alternative Text for Images that Convey Content
- Visible Text labels *associated with* Form inputs
- Proper titles for Frames and iFrames
- Captions, Transcripts, and Descriptions of media
- Don't use color alone for information (e.g. an error)
]
---
# POUR: Perceivable: Guidelines 1.1-1.4
.left-column[
## Guideline 1.2
Provide perceivable alternatives for time-based media
]
.right-column[
Includes: audio-only; video-only; audio-video; audio and/or video combined with interaction
Best practices vary depending on whether it is recorded or live, and the type of media, and include:
- Video Description
- Captions
- Transcripts
- ASL interpretation
]
???
Kind of in 1.1 but also complicated so it gets its own guideline.
---
# Making Video/Animation/Audio Accessible
Relevant for slides; web; anywhere
Understandable live & recorded video for people who are not able to hear audio
Understandable live & recorded video for people who are not able to see the screen
Other factors such as avoiding seizures & so on
???
delete avoiding seizures next year
---
# Captioning Videos
Auto captioning getting better, but still makes many errors
- Does not easily support multilingual settings
- Errors for people with accents
- Errors for proper nouns and names
Best practice is manual captioning and/or ASL live, or pre-recorded
Easy to apply and then correct auto captioning with existing tools (e.g. YouTube has an interface)
- You will be expected to do this if you use video in any homeworks
---
# Audio Describing Videos
May requiring pausing video, but skillful description usually possible without that
More commonly available today than ever
Let's try it: Form groups and open [YouDescribe](https://youdescribe.org/);
([post a link to your video](TBD))
If you want to know more: [describing educational videos](https://dcmp.org/learn/descriptionkey)
---
# POUR: Perceivable: Guidelines 1.1-1.4
.left-column[
## Guideline 1.3
Adaptable
]
.right-column[
Ensure that all information is available in a form that can be perceived by accessibility tools (and thus spoken aloud, simplified, etc)
This includes information that is not encoded in text such as
- page organization
- relationships
- cross-site or cross-app organization
- other structural information
]
???
Example: spoken aloud, or presented in a simpler visual
Structure and information should be able to be programmatically determined by assistive technology, so it can be rendered in other formats as needed by the user.
---
# POUR: Perceivable: Guidelines 1.1-1.4
.left-column[
## Guideline 1.3
Adaptable
]
.right-column[
Examples/subcategories of guideline:
- Make it possible to get information about relationships, footnotes, etc in multiple modalities
- Sequence things correctly (e.g. linear reading order is meaningful in a multi-column document)
- Make sure instructions rely on multiple senses (i.e. not just color, size, location, etc)
- Support multiple display sizes and orientations
- Clearly identify input and field purposes in forms
]
???
Also in 1.1 but complicated enough to get it's own guideline
Many of these should/can be supported programmatically
---
# POUR: Perceivable: Guidelines 1.1-1.4
.left-column[
## Guideline 1.4
Distinguishable
]
.right-column[
- Make the default presentation as easy to perceive as possible to people with disabilities.
- Example: separate visual foreground information from the background
- color contrast
- volume contrast
]
---
# POUR: Perceivable: Guidelines 1.1-1.4
.left-column[
## Guideline 1.4
Distinguishable
]
.right-column[
- Use of color is not the only way information is conveyed
- Audio longer than 3s should provide easily found controls; ideally use low or no background audio
- Support text resizing (& therefore don't use images of text). (AAA) supports changing color; justification, etc
- Support a 1 column view of content (AAA)
- Avoid tooltips and popups; make sure they are: dismissable; hoverable; and persistent
- Meet contrast expectations (min 4.5:1, ideally 7:1) in color (e.g. text and background; diagrams; controls; etc)
]
---
# More on Color contrast
Choose colors that provide enough contrast between content and the background so that anyone with low-vision impairments and color deficiencies can perceive the content.
.left-column50[
WCAG Level AAA requires a contrast ratio of at least
- .contrast71[7:1 for normal text]
- .contrast41[4.5:1 for large text (14t pt bold or larger)]
- .badcontrast[Avoid anything else!]
]
.right-column50[
- [Colorzilla](https://chrome.google.com/webstore/detail/colorzilla/bhlhnicpbhignbdhedgjhgdocnmhomnp?hl=en) is an excellent tool for extracting the color value from any page element;
- WebAIM has a [contrast checker](https://webaim.org/resources/contrastchecker/#:~:text=WCAG%20Level%20AAA%20requires%20a,value%20from%20any%20page%20element)
]
---
# Field Trip
Try out [WebAIM for the UW Library](https://wave.webaim.org/report#/https://www.lib.washington.edu/)
???
Talk about how the type of errors found relates to the concepts we've discussed so far
---
# Small Group Activity
Try it yourself [WebAIM for Seattle Public Schools](https://wave.webaim.org/report#/https://www.seattleschools.org/)
The task you are evaluating is whether a disabled family can "Report a Concern" about how accessible the website is
[Post your UAR on Ed](https://edstem.org/us/courses/31170/discussion/2349808)