A lot of Javascript gets tested, but DOM interactions and accessibility are often left to human testers. This talk reviews different testing strategies and outlines my take on automated tests for front-end development.

1. The Strange DOM:
Or How I Learned to Stop Worrying
and Test For Accessibility

2. Trevor Pierce
• User experience designer
• Javascript mucker-arounder
• Accessibility advocate and advisor

3. Accessibility is difficult…
it starts out easy…but it ends up difficult.

4. Radio buttons:
<fieldset id=“shipping-speed”>
<legend>Select a shipping speed:</legend>
<ul class="controlList" aria-labelledby=“shipping__header">
<li><label for="p3_opt1"><input id="p3_opt1" type="radio" name="shipping-radio"
value="Standard" />Standard 3-5 Business Days</label></li>
<li><label for="p3_opt2"><input id="p3_opt2" type="radio" name="shipping-radio"
value="Two Day Air" />2 Day Air</label></li>
<li><label for="p3_opt3"><input id="p3_opt3" type="radio" name="shipping-radio"
value="Overnight" />Overnight Air</label></li>
</ul>
</fieldset>

5. Checkboxes:
<h3 id="size__header">Sizes</h3>
<ul class="controlList" aria-labelledby="size__header">
<li><label for="p2_opt1"><input id="p2_opt1" type="checkbox" name="extra small"
value="Extra Small" />Extra Small</label></li>
<li><label for="p2_opt2"><input id="p2_opt2" type="checkbox" name="small"
value="Small" />Small</label></li>
<li><label for="p2_opt3"><input id="p2_opt3" type="checkbox" name="medium"
value="Medium" />Medium</label></li>
<li><label for="p2_opt4"><input id="p2_opt4" type="checkbox" name="large"
value="Large" />Large</label></li>
<li><label for="p2_opt5"><input id="p2_opt5" type="checkbox" name="extra large"
value="Extra Large" />Extra Large</label></li>
</ul>

6. “Tell no one of this.”

7. 1. Incomplete specs, no clear best practices
2. No clear guidance like other industrialized nations.
Section 508? WCAG? Which standard?
3. Designers. Designers?!?
(Let me explain.)
Some challenges:

8. “This’ll be great.”

9. • Tabs,
• Mega menus,
• Typeaheads, oh my!
• These rich widgets are NOT accessible
without developer intervention
Designers like widgets:

10. “So what now, funny man?”
— Some testing strategies

11. • Can’t account for all types of colorblindness
• Screen reader testing is like 2-3 additional browsers
• Error-prone, humans are better suited to logic and
judgment-call testing
Only human testing

12. Only human testing
— The digital equivalent to…

13. • More comprehensive than human testing alone
• Can identify issues with static, and dynamic elements
• Not as helpful after the fact
• Longer remediation timelines, bigger budgets
• More difficult to refactor code later
Production code scans

14. Production code scans
— The digital equivalent to…

15. The new hotness
— How I’m doing what it is I do

17. • Fixtures to test HTML in isolation, one module at a time
• Test suite loads a new fixture for each test
• Suite tests click, focus, blur, keypress, and combo events
• Suite runs aXe accessibility test after DOM manipulations
• Human testing as a final check. Seeing is believing.
A new take on testing

18. “Show us yer codez.”

19. “Denouement”

20. • Read the specs, challenge the rules. I opened 3 bug
fixes, just by reading, and referencing the WCAG spec.
• Advocate for QA (human, automated) in your projects
• Write tests! Unit tests are cheap, and effective.
• Fork and improve:
https://github.com/1Copenut/C3/tree/develop
Contribute to #a11y