Assessment 2 --Week 3--

background-image: url(img/people.png)

.left-column50[
# Week 3: More Assessment!

CSE493e, Fall 2024
]
---
name: normal
layout: true
class:

---
# Important Reminder

.left-column[
![:qrhere](nil)]

## Make sure zoom is running and recording!!!
## Check on zoom buddies
## Make sure captioning is turned on

---
[//]: # (Outline Slide)
# Learning Goals for Today

- Remainder of POUR: accessibility standards (2 and 3 and 4)
- More on how to assess websites / implement changes

---
# POUR: Operable: Guidelines 2.1-2.5

.left-column[
## Guideline 2.1 (1/5)
Keyboard Accessible
]
.right-column[

Keyboards are uniquely flexible & pretty universal

Keyboards are operable  by people with most disabilities

Examples of who benefits
- screen reader users (e.g. blind users, reading disabilities)
- speech input users
- switch input users
]

---
# POUR: Operable: Guidelines 2.1-2.5

.left-column[
## Guideline 2.1 (2/5)
Keyboard Accessible
]
.right-column[
But we need to think about keyboard accessibility when using all apps
- Drawing program
- Drag and Drop
- Drone control
- Game play
- Website navigation 
- ...
]
---
# POUR: Operable: Guidelines 2.1-2.5

.left-column[
## Guideline 2.1 (3/5)
Keyboard Accessible
]
.right-column[
Some common pitfalls:

- Keyboard Traps. 
  - "Trap" keyboard focus within areas of a page
  - Occurs when multiple formats are combined  using plug-ins/embedded applications.
]

???
Problem if you are using tab to navigate (for example)

---
# POUR: Operable: Guidelines 2.1-2.5

.left-column[
## Guideline 2.1 (4/5) 
Keyboard Accessible
]
.right-column[
Some common pitfalls:

- Keyboard Traps.
- Invisible Content. Some parts of a web page can never be reached
]
---
# POUR: Operable: Guidelines 2.1-2.5

.left-column[
## Guideline 2.1 (5/5) 
Keyboard Accessible
]
.right-column[
Some common pitfalls:

- Keyboard Traps.
- Invisible Content. Some parts of a web page can never be reached
- Lack of Control. Users should be able to reconfigure or remove shortcuts
]

???
Note: Not in guidelines (that I know of) but a "reverse trap" is whether you can reach text that *doesn't* have links or headers when using switch input. How would you do this?

Character key shortcuts work well for many keyboard users, but are inappropriate and frustrating for speech input users — whose means of input is strings of letters — and for keyboard users who are prone to accidentally hit keys. To rectify this issue, authors need to allow users to turn off or reconfigure shortcuts that are made up of only character keys.

---
# POUR: Operable: Guidelines 2.1-2.5

.left-column[
## Guideline 2.2 (1/2)

Enough Time
]
.right-column[
Timed content includes rotating content; timeouts; etc

Many users who have disabilities may need more time to complete tasks
- To physically respond
- To read things
- To find things (e.g. due to low vision)
- To accessing content through an assistive technology (e.g. single switch)
]

---
# POUR: Operable: Guidelines 2.1-2.5

.left-column[
## Guideline 2.2 (2/2)

Enough Time
]
.right-column[
- Make timelines adjustable if necessary
   - Able to resume after timeout without data loss
- Warn users about time limits
- Provide controls (Pause, Stop & Hide) for blinking text and animations 
- Let users postpone or suppress interruptions 
- Interruptions involving an emergency still appear (AAA)
]

---
exclude: true

# POUR: Operable: Guidelines 2.1-2.5

.left-column[
## Guideline 2.3 (1/2)

Seizures and Physical Reactions
]
.right-column[
In 1997, a cartoon on television in Japan sent over 700 children to the hospital, including about 500 who had seizures.
 - Most people are unaware that they are triggered until it strikes. 
 - Warnings do not work well because they are often missed, especially by children who may in fact not be able to read them.
]

???
It is possible to avoid these types of flashes and still create appealing apps/websites

---
exclude: true

# POUR: Operable: Guidelines 2.1-2.5

.left-column[
## Guideline 2.3 (2/2)

Seizures and Physical Reactions
]
.right-column[
-  Web pages do not contain anything that flashes more than three times in any one second period
- Motion animation triggered by interaction can be disabled, unless the animation is essential to the functionality or the information being conveyed (AAA)
]

---
# POUR: Operable: Guidelines 2.1-2.5

.left-column[
## Guideline 2.4 (1/5)

Navigable
]
.right-column[
Can the user

- Orient themselves within the overall app
- Find the content they need
- Go somewhere they want to go?
- Keep track of their location?

Connections: Guideline 1.3 (Structure can be perceived);  1.3.1 (Use headings)
]

---
# POUR: Operable: Guidelines 2.1-2.5

.left-column[
## Guideline 2.4  (2/5)

Navigable
]
.right-column[
- Can orient oneself & find content
- Can jump over uninteresting content
]
???
examples: Navigation (that is the same on every page on a site); Anything that is not the news article (on a news site); Advertisements; etc. 
---
# POUR: Operable: Guidelines 2.1-2.5

.left-column[
## Guideline 2.4 (3/5)

Navigable
]
.right-column[
- Can orient oneself & find content
- Can jump over uninteresting content
- Titles, links & headings descriptive 
   - Each page has descriptive title
   - Links have informative link text
   - Headings and labels 
      - Describe topic and purpose
	  - Have meaningful heading levels
	  - Are not used solely for styling (styling is handled through CSS)
   
]
---

# POUR: Operable: Guidelines 2.1-2.5

.left-column[
## Guideline 2.4 (4/5)

Navigable
]
.right-column[
- Can orient oneself & find content
- Can jump over uninteresting content
- Titles, links & Headings descriptive
- Focus is usable
   - Focus order makes sense. 
   - This can be problematic in any web page
   - Requires special support when navigating trees and tables.
   - Focus is visible (A); perceivable (AA) & obscured by other content (A)
]

---
# POUR: Operable: Guidelines 2.1-2.5

.left-column[
## Guideline 2.5 (1/5)

Pointers alone should  be able to access everything
]
.right-column[

- All functionality should be accessible via pointers
- Don't require timed or complex gestures. Examples 
  - drag-and-drop gestures and on touch screens
  - swiping gestures
  - split taps
  - long presses
  - multi-finger gestures
  - tilting based interactions
]

---
# POUR: Operable: Guidelines 2.1-2.5

.left-column[
## Guideline 2.5 (1/5)

Pointers alone should  be able to access everything
]
.right-column[

- All functionality should be accessible via pointers
- Don't require timed or complex gestures. Examples 
- Don't require selecting small targets, or high precision (i.e. due to tremor)
  - 24x24 CSS Pixels (AA) 
  - 44x44 CSS Pixels (AAA)
  - 48x48 (Mobile)
]

---
# More on Size

.left-column40[
Especially hard on mobile devices

![:img An arrow vs arrow and label make very different target sizes ,80%, width](img/assessment/targets.png) 
]

.right-column60[
Can make targets larger than their visual error
- Reduces errors
- Still intuitive 
- White space around targets also helps
]
???
Solve for one, extend to many
Trying to hit a small button with one hand while standing on a moving, crowded bus

---
exclude: true

# POUR: Operable: Guidelines 2.1-2.5

.left-column[
## Guideline 2.5 (2/5)

Pointers alone able to access everything
]
.right-column[
- Support a variety of input options
   - avoid path based gestures when possible; 
   - offer alternatives to path based gestures or multi-finger gestures
   - provide programmatic alternatives to shaking or tilting or dragging based interaction
   - **overall goal**: allow users to use multiple possible types of input (keyboard, pointer, on-screen keyboard, stylus, etc)

]

???

including a single pointer; offer alternatives to gestures and other physical actions
---
# POUR: Operable: Guidelines 2.1-2.5

.left-column[
## Guideline 2.5 (3/5)

Pointers alone should be able to access everything
]
.right-column[
- All functionality should be accessible via pointers
- Don't require timed or complex gestures
- Trigger content only on *up* events (after a complete click)
]
---
# POUR: Operable: Guidelines 2.1-2.5

.left-column[
## Guideline 2.5 (4/5)

---
# Finding 2.1-2.5 Violations

- 2.1 Keyboard Accessible
- 2.2 Enough Time
- 2.4 Navigable
- 2.5 Pointers alone should  be able to access everything

How would you check each of these in WebAIM? Using Accessibility Technology? 
([post](https://edstem.org/us/courses/67367/discussion/5428437))

---
# QUICK BREAK

Good time to stand and stretch