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