This document discusses how to write effective accessibility bug reports. It provides examples of good bug titles and descriptions, emphasizes including expected results, reproduction steps, and attachments. It also discusses prioritizing bugs by severity and impact on users. The goal is to write clear, actionable bugs that help developers understand and fix issues to improve accessibility for all.

1. ode to an
accessibility bug
wendy chisholm, entomologist
microsoft
sp1ral.com/about
t: wendyabc
o’: universal design
for web apps

2. backstory
beneficial bugs
brain spirals
bug bait
better bugs

3. backstory

4. Does the alt key on the keyboard have
anything to do with alt text?

5. brain spirals

6. Mr. Miyahi: Learning to coach
• Wax on, Wax off
• Small Steps==bugs
• Training, Practice, Do
it better

7. Spiral model

8. Take away: Training/Dev Resources
• HTML
• WAI-ARIA 1.0 Authoring Practices, Design Patterns, W3C
• Using ARIA in HTML, W3C
• Accessibility 101, SSB Bart Youtube video series
• Android
• Accessibility Testing Checklist
• Talkback gestures
• iOS
• iOS accessibility (WWDC 2014), iOS accessibility (WWDC 2015)
• Watch accessibility (WWDC 2015)
• iOS Accessibility, Apple Dev Center
• iOS vs Android Paul Adam, Deque
• Windows Accessibility Developer Hub

9. beneficial bugs

10. Agile Development Software Lifecycle

11. Cost to fix a bug versus time when a bug is
found

12. What makes a good bug?
1. Descriptive title
1. [P]roblem [A]ction [L]ocation
2. <= 140 characters
2. Concise description
3. Clear expected results
4. Details about project, version
5. Platform details
6. Type and severity
7. Steps to reproduce
8. Visual attachment
9. Tags and links
Lean Testing: How to write a good bug report

13. What makes a good accessibility bug?1. Descriptive title
1. [P]roblem [A]ction [L]ocation
2. <= 140 characters
2. Concise description, IMPACT
3. Clear expected results
4. Details about project, version
5. Platform details, AT
6. Type and severity
7. Steps to reproduce
8. Visual OR VIDEO attachment
9. Tags and links

14. bug bait

15. A toolbox of tools

16. Tools that I use• Automated
• Tenon, aXe, Chrome Audit
• F12 team looking for input,
Aaron Gustafson tweet
• Inspection
• WAVE, WAT
• Access technologies
• Screen readers, magnification
• High contrast, speech
recognition
• Color contrast

17. better bugs

18. Example: All widgets need to be in the tab
order
• Title: All widgets on example.com
need to be in the tab order
• Expected results: The user should
be able to tab to all widgets on the
page.
• Steps to reproduce:
1. Go to example.com
2. Press the tab key 15 times to
go from top of page to
bottom
3. Note that the navigation
buttons are not in the tab
order
• Visual attachment: screen shot
of example.com with navigation
buttons circled in red

19. What was the result?
• Result? “Won’t fix”
• Wrote JavaScript, killed
performance
• Filed a new bug…

20. Rewriting the bug
• Title: Use tabindex=0 to put
navigation buttons in the tab
order
• Other info same/similar
• Links
• WAI-ARIA Best Practices,
“Using tabindex to manage
focus among widgets.”

21. Another example: all widgets need to be
spoken by a screen reader• Title: All widgets need to be
spoken by a screen reader
• Expected results: Using a screen
reader, the user should be able to
hear all widgets on the page.
• Steps to reproduce:
1. Go to example.com in Firefox
with NVDA
2. Press the tab key to navigate
between widgets
• Visual attachment: screen shot
of example.com with buttons
circled in red

22. How did that one work out?
• Result? “We fixed it”
• Great! User testing.
• Button, group, new caption…

23. Trying again…
• Title: All widgets need to have a
sensible name spoken by a screen
reader
• Expected results: Using a screen
reader, the user should be able to
hear all widgets on the page.
• What happened instead: Buttons
x, y and z were read as “button”
instead of x, y, z
• Steps to reproduce:
1. Go to example.com in Firefox
with NVDA
2. Press the tab key to navigate
between widgets
• Video attachment: recording of
what happened in their app vs
what happens in competitor app

24. Severity:
From Low
to Snakes
• Severity:
• Impossible
• Prohibitive
• Difficult
• Distracting
• Before: everything was severe
• WCAG 2.0 Level A, AA
• Now: Stack rank, roadmap

25. Severity scaleSeverity scale
1. Sev0 – Impossible/Severe
• Button not in tab order
2. Sev1 – Prohibitive/Major
• Incorrect role
3. Sev2 – Difficult/Minor
• Unintuitive tab order
4. Sev3 – Distracting/Trivial
• Spelling errors

26. • Create a roadmap
• Coaching progression
• Severity
• Priority
• User Feedback
Coaching 101

27. What makes a good accessibility bug?1. Descriptive title
1. [P]roblem [A]ction [L]ocation
2. <= 140 characters
2. Concise description, IMPACT
3. Clear expected results
4. Details about project, version
5. Platform details, AT
6. Type and severity
7. Steps to reproduce
8. Visual OR VIDEO attachment
9. Tags and links

28. 1. FixTheWeb
1. Fixtheweb.net
2. Twitter: @FixTheWeb
2. Disability Answer Desk
1. aka.ms/accessibilitysupport
2. Twitter: @MSFTEnable
Send us bugs

29. ….and so

30. Stairs
make a building
inaccessible
not a
wheelchair

31. ode to an
accessibility bug
wendy chisholm, entomologist
microsoft
sp1ral.com/about
t: wendyabc
o’: universal design
for web apps