The Strange DOM:

Or How I Learned to Stop Worrying

and Test For Accessibility

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

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

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>

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>

“Tell no one of this.”

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:

“This’ll be great.”

• Tabs, • Mega menus, • Typeaheads, oh my! • These rich widgets are NOT accessible

without developer intervention

Designers like widgets:

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

• 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

Only human testing — The digital equivalent to…

• 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

Production code scans — The digital equivalent to…

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

• 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

“Show us yer codez.”

“Denouement”

• 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