Web Accessibility
Hacker Way
Why?
Because we want to empower EVERY person on the planet
When we design our websites to be accessible, we make our websites better for EVERYONE
It is required by law
3 steps to be 80% accessible
Website is usable with keyboard only
Smart focus management
Website can be used with screen reader
Website is usable with keyboard only
focus outline is visible
no extra/unnecessary tabstops
no tabstop traps
Smart focus management
set focus on appropriate elements after user actions
restore focus to appropriate elements after user actions
make tab order user friendly
Website can be used with screen reader
When element gets focused, screen reader should provide meaningful information
Min bar: Make it work with Chrome + NVDA
The best ARIA is no ARIA
Add aria-* tags if needed (to help screen reader)
Tips & Tricks
use common sense and your own judgement
use native HTML elements when possible
only 30% can be verified by tools
Ibiza Tips & Tricks
[Impl] KeyboardShortcutHandler.ts
[QUnit] KeyboardShortcutHandler.test.ts
[Selenium] KeyboardShortcutTests.cs
use waitForBindings() to set focus
use Interactions.DismissHandler to restore focus
Why keydown?
keypress does not work for special keys (e.g., ESC, ARROWS)
with keyup you cannot detect two keys (e.g., ? == SHIFT+/)
if needed: add separate handlers
Handling Keyboard
$element.on(EventTypes.keydown, evt => {
if (evt.which === Util.KeyCode.Enter
&& KeyboardHelper.getModifierKeys(evt) === ModifierKeys.None) {
// do stuff
return false;
}
});
$element.on(EventTypes.keydown, evt => {
if (evt.which === Util.KeyCode.Enter
&& KeyboardHelper.getModifierKeys(evt) === ModifierKeys.None) {
// do stuff
evt.stopPropagation();
evt.preventDefault();
}
});
Unit testing keyboard
// emulate pressing key
TypingEmulator.writeKeyCode(element, KeyCode.H);
// checking for focused element
strictEqual(document.activeElement, element2);
// checking for focused element async
TestHelper.strictEqualAsync(
() => document.activeElement, element2);
UI testing keyboard
// emulating user key press
webDriver.SwitchTo().ActiveElement().SendKeys("h");
// might be flakey if executed right after key action
Assert.IsTrue(IsFocused(element));
// better, async assert
webDriver.WaitUntil(() => IsFocused(element));
// checking for focus with Selenium
bool IsFocused (IWebElement element) {
return Equals(webDriver.SwitchTo().ActiveElement(), element);
}
// checking for focus with JavaScript
bool IsFocused (string element) {
return Convert.ToInt32((webDriver as IJavaScriptExecutor)
.ExecuteScript("return document.activeElement == " + element)) == 1;
}
Tools
Chrome Accessibility Audit
Keros (aka KFC = Keros For Chrome)
http://toolbox/keros
AXE
http://www.deque.com/products/axe/
Accessibility
=
Performance First
References
?
Questions
Web Accessibility Hacker Way
By Jakub Jedryszek
Web Accessibility Hacker Way
If you would print entire Web Accessibility specification, and stack it, it would be higher than CN Tower in Toronto (553 meters = 1814.3 feet). However, there is a way how you can fulfill 80% of this specification with 20% of effort, without even reading it. Let's find out what's the web accessibility hacker way
- 1,348