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.
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:
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
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
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
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