WCAG for Milestone 3: Keyboard, Focus & Headings

# WCAG for Milestone 3: Keyboard, Focus & Headings
The four WCAG criteria your team will audit in Milestone 3, and how to test them

cse482a: Fall 2026; Jennifer Mankoff (Last Edited: 2026-10-28). <a href="/courses/cse482a/26au/slides/wcag-interaction.html">Live View: /slides/wcag-interaction.html</a>

Important Reminder: check zoom & captioning

---

<div class="slide-outline" style="margin: 1em 0; padding: 1em; background: #f5f5f5; border-radius: 5px;">
<h2 style="margin-top: 0;">
  
  
    Outline
  
  
</h2>
    
  <ul style="list-style-type: none; padding-left: 0;">
  
  
  
  
  
  
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
      
        
        
      
    
      
        
        
          
            
            
              
              
                
                  
                  <li><a href="#3">Audit in action</a> (Slide 3)</li>
                
                
              
            
          
        
      
    
      
    
      
    
      
    
      
    
      
    
      
    
      
    
      
    
      
    
      
    
      
    
      
    
      
    
      
    
      
    
      
    
      
    
      
    
      
    
      
    
      
    
      
    
      
    
      
    
      
    
      
    
      
    
      
    
      
    
    
    
    
    
  
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
      
        
        
      
    
      
        
        
          
            
            
              
              
                
                  
                  <li><a href="#6">In pairs: audit a real page</a> (Slide 6)</li>
                
                
              
            
          
        
      
    
      
    
      
    
      
    
      
    
      
    
      
    
      
    
      
    
      
    
      
    
      
    
      
    
      
    
      
    
      
    
      
    
      
    
      
    
      
    
      
    
      
    
      
    
      
    
      
    
      
    
      
    
      
    
      
    
      
    
      
    
      
    
      
    
      
    
      
    
      
    
      
    
      
    
      
    
      
    
      
    
      
    
      
    
      
    
      
    
      
    
      
    
      
    
      
    
      
    
      
    
      
    
      
    
      
    
      
    
      
    
      
    
      
    
      
    
      
    
      
    
      
    
      
    
      
    
      
    
      
    
      
    
      
    
      
    
      
    
      
    
      
    
      
    
      
    
      
    
      
    
      
    
      
    
      
    
      
    
      
    
      
    
      
    
      
    
      
    
      
    
      
    
      
    
      
    
      
    
      
    
      
    
      
    
      
    
      
    
      
    
      
    
      
    
      
    
      
    
      
    
      
    
      
    
      
    
      
    
      
    
      
    
      
    
      
    
      
    
      
    
      
    
      
    
      
    
      
    
      
    
      
    
      
    
      
    
      
    
    
    
    
    
  
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
      
        
        
      
    
      
        
        
          
            
            
              
              
                
                  
                  <li><a href="#16">Now try the fixed version (10 min)</a> (Slide 16)</li>
                
                
              
            
          
        
      
    
      
    
      
    
      
    
      
    
      
    
      
    
      
    
      
    
      
    
      
    
      
    
    
    
    
    
  
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
      
        
        
      
    
      
        
        
          
            
            
              
              
                
                  
                  <li><a href="#17">In your team: your own project</a> (Slide 17)</li>
                
                
              
            
          
        
      
    
      
    
      
    
      
    
      
    
      
    
      
    
      
    
      
    
      
    
      
    
      
    
      
    
      
    
      
    
      
    
      
    
      
    
      
    
      
    
      
    
      
    
    
    
    
    
  
  </ul>
</div>

---
class: center, middle, inverse
# Audit in action
Keyboard, focus, and headings

---
## Plan for today (80 minutes)

| Time | What |
|---|---|
| 5 min | Review and today's four criteria |
| 40 min | **In pairs:** audit a real page with keyboard and screen reader |
| 10 min | Try the fixed version |
| 20 min | **In your team:** audit your own project |
| 5 min | Wrap up |

These four criteria go in the **Milestone 3** audit, for what you have *implemented*.

---
## Review

- Last Monday you wrote VPAT rows for 1.1.1, 1.4.3 and 1.4.11
- Each row: **Conformance Level** (Supports / Partially Supports / Does Not Support) and an explanation naming **which** feature, **how** it falls short, and **who** is affected
- Today adds four rows, using the *same* table

| Criterion | Level | Question |
|---|---|---|
| 2.1.1 Keyboard | A | Can everything be done from a keyboard? |
| 2.4.7 Focus Visible | AA | Can you see where focus is? |
| 2.4.3 Focus Order | A | Does tabbing move in a sensible order? |
| 1.3.1 Info and Relationships (headings) | A | Do heading levels show the real structure? |

---
class: center, middle, inverse
# In pairs: audit a real page

---
## Setup

Same pairs as Monday: one **laptop**, one **phone**.

Load [(in)Accessible University](https://projects.accesscomputing.uw.edu/au/before.html) on the laptop.

**Put the mouse away.** For the first four steps, use only the keyboard: `Tab`, `Shift+Tab`, `Enter`, `Space`, and the arrow keys.

---
## Step 1: Keyboard (2.1.1), 10 min

**The criterion (Level A):** all functionality must work with a keyboard.

Who relies on this: screen reader users, speech input users, switch users, people with motor disabilities.

**Pitfalls:** keyboard traps (you can tab in but not out), content that can never be reached, controls that only respond to a mouse.

**Do it:** with the keyboard only,
1. Open the **navigation menu** and its sub-menus
2. Move through the **carousel**
3. Try to open the **modal window**, if you can find one
4. Fill in and submit the **form**

Write down what you could *not* do.

---
## Step 1: Write the row

| Criteria | Conformance Level | Brief Explanation |
|---|---|---|
| 2.1.1 (Keyboard) | ? | Which features, what stopped you, who is affected |

What we expect to find: the sub-menus that appear on mouse hover **do not appear** when you reach them by tab, and the menu items don't send you to a new page. The issues list also calls out the carousel and the modal window.

???
The AU issues list names the inaccessible dropdown menu, the inaccessible modal window (#14) and the inaccessible carousel (#15). Let pairs find them first.

---
## Step 2: Focus visible (2.4.7), 5 min

**The criterion (Level AA):** when a control has keyboard focus, you must be able to *see* it.

```css
/* Good */
#send-feedback-btn:focus { outline: 2px solid #0000ff; }
/* Bad: removes the focus ring and puts nothing back */
button:focus { outline: none; }
```

**Do it:** `Tab` through the page and watch. Can you always tell where you are? Where do you lose it?

**Write the row** for 2.4.7. Hint: compare what happens when you *hover* with a mouse with what happens when you *tab*.

---
## Step 3: Focus order (2.4.3), 8 min

**The criterion (Level A):** focus should move in an order that preserves meaning and operability.

- It usually follows the order of elements in the HTML. CSS layout can break that
- Opening a dialog should move focus *into* it; closing it should return focus

**Do it:**
1. `Tab` through the page. **Say the order out loud**
2. Open the **Order** tab in [WAVE](https://wave.webaim.org/report#/https://projects.accesscomputing.uw.edu/au/before.html)
3. Does it match how you would read the page?

Also: is there a **skip link** (a way to jump over the navigation)? **Write the row** for 2.4.3.

---
## Step 4: Headings (1.3.1), 8 min

**The criterion (Level A):** structure you can see must also be in the code, so assistive technology can use it.

- Use real heading elements (`h1`, `h2`, `h3`), not bold or large text
- Levels reflect structure: don't skip levels
- Choose a level for its **meaning**, style it with CSS

**Do it:** in WAVE, open the **Structure** tab. Read *only* the heading outline. Does it make sense as a table of contents? Compare it to what you *see* on the page.

**Write the row** for 1.3.1 (headings).

---
## Steps 3 and 4: What we found

- The visible headings are **not marked up as headings**: they are plain bold, large text. A screen reader user cannot jump between them
- Where headings *are* used, they are used for **style**: an `
<h5>
  
  
    ` just to make a date smaller
- Missing **skip link**: keyboard users must tab through the whole menu on every page
- Check the focus order: does the visual order match the tab order?

Compare notes with another pair. What did they find that you didn't?

---
## Step 5: Screen reader, 15 min

Now add a screen reader.

- macOS: `command` + `F5` (or Settings, search for VoiceOver). Use VO = `control` + `option`
- iPhone: Settings, Accessibility, VoiceOver. Swipe to move between elements

**Do it:**
1. Read the page title
2. Pull up the **headings list** (VO rotor): is it useful?
3. Move through the page. Check **alt text**, **roles** ("navigation", "button") and **headings**
4. Try to operate the **form**

Add anything you find to your rows.

---
## Step 5: Some things to notice

- "Required fields in blue" is not visible to a screen reader user
- You may not be able to finish the form: it doesn't tell you **where the error** is
- Form labels may be read **twice** on a laptop
- Missing skip link; heading levels inconsistent with meaning; carousel not accessible

You can't do this from **WAVE alone**. A screen reader and a keyboard find what a tool can't.

---
name: fixed-version
## Now try the fixed version (10 min)

Load [Accessible University](https://projects.accesscomputing.uw.edu/au/after_u.html). Keep the screen reader on.

With your partner:
1. Do the keyboard steps again: do the menu, carousel and form now work?
2. Is focus now always visible?
3. Look at the heading outline in WAVE. What changed?
4. Is anything *still* a problem?

The full [list of issues](https://a11y-assessments.pages.oit.duke.edu/accessible-u/issues.html) explains each problem and its fix.

---
class: center, middle, inverse
# In your team: your own project

---
## Your project (20 min)

1. Pick **one screen or flow** you have *implemented*. (If you have not implemented much yet, use your website, or a similar existing page, to practice)
2. Test it for **all four** criteria: keyboard, focus visible, focus order, headings
3. Write a VPAT row for each. Name **which** feature, **how** it falls short, and **who** is affected
4. Say what you **did not test**

Ask a TA to read one row.

???
Circulate. Common issues: custom controls that do nothing on Enter; focus lost after a modal closes; `outline: none`; headings chosen for size rather than meaning.

---
## Wrap up

- **Milestone 2 is due Wed 11/4** (VPAT rows for contrast and alt text, website check, alt text list)
- **Milestone 3** (11/18) audits what you have implemented against today's four criteria
- Questions?