Manuel Matuzovi ć

   @mmatuzo

pitercss 06/2017 UX ACCESSIBLE

Manuel Matuzovic

Manuel Matuzovi ć

č , ć , đ , d ž , š , ž , nj, lj q , w,

x

K eyboard layout s “A keyboard layout is any specific mechanical, visual, or functional arrangement of the keys, legends, or key-meaning associations (respectively) of a computer, typewriter, or other typographic keyboard.” Wikipedia

QWERTY

QWERTZ

AZERTY

JCUKEN

Soooo?

event.keyCode window . addEventListener ( 'keydown' ,

navigate );

function

navigate ( e ) {

...

if

( e . keyCode

===

68 ) {

moveLeftAndRight ( 1 );

}

if

( e . keyCode

===

90 ) {

shootMissile ();

}

Issues • Different meaning of properties when handling a key event (keydown or keyup) versus a character event (keypress).

• The values of keys in keypress events are different between browsers.
• Inconsistent values for keys and events cross-browser
• keyCode on key events tries to be international-friendly , but isn’t

w s a d z forward back le (

right shoot A W S D Z

QWERTY QWERT Z

QWERTY

Remember AZERTY?

UI Events: API • Two new properties: key and code • event.key

printable character or a descriptive string , e.g. z • event.code
physical key, e.g. KeyY

• Reference keyboard in the specification

Reference keyboard

window . addEventListener ( 'keydown' ,

navigate );

function

navigate ( e ) {

...

if

( e . code

===

'KeyD' ) {

moveLeftAndRight ( 1 );

}

if

( e . code

===

'KeyY' ) {

shootMissile ();

}

event.keyCode

Browsersupport

switch (e.code || e.keyCode ) {

...

case

'KeyD' :

case

'ArrowRight' : case

39 :

moveLeftAndRight ( 1 );   ...

}

Fallback

Notes • There is no way of checking for the current keyboard layout.
• Use the repeat property to check if the user keeps pressing a key and the event is sent repeatedly
• Boolean properties for modifier keys ( altKey, ctrlKey, metaKey, shiftKey ). • Still a Working Dra " : There are some inconsistencies between browsers.

https://codepen.io/matuzo/pen/PmgWRm?editors=0010

T WEETABLE TAKE-AWAY The web is international and so are your users. Don’t assume that all users use the same input devices.

lang a ) ribute

<!DOCTYPE html > <html

lang

"en"

<head> <title> Document </title> </head> <body> </body> </html>

lang a ) ribute

lang a ) ribute: impacts • Assistive Technology • Translation tools and browsers • Quote characters

• Date and Number inputs • Search engines

• Hyphenation

T WEETABLE TAKE-AWAY Make sure to tell the browser the correct language in use. Everyone benefits from it.

keyboard usage

Surfing the web without a mouse sucks…

…and it’s our fault!

BUT!

We can fix it!

Missing or insu ﬃ cient focus styles

{

outline :

none ;

} :focus styling

a : focus

{

color :

#FF00FF ;

} :focus styling

a : focus-ring

{

outline :

1px solid #FF00FF ;

} :focus -ring Polyfill: https://github.com/WICG/focus-ring

form : focus-within

{

background : #FF00FF ;

} :focus -within

Browsersupport

Tabbable/focusable elements • Input elements, selects, textareas

• Links

• Contenteditable elements • audio, video with controls

• …

tabindex (focusable and tabbable)

<h2

tabindex

"0"

A focusable heading

</h2>

<h2

tabindex

"-1"

A focusable heading

</h2> tabindex ( just focusable)

Bad Semantics

<button> I'm a button </button> Bu ) ons vs. “Bu ) ons ” <div

class

"btn"

I'm a div

</div> <div

class

"btn"

tabindex

"0"

I'm a div

</div>

<div

class

"btn"

I'm a div

</div> <div

class

"btn"

tabindex

"0"

I'm a div

</div> <div

class

"btn"

tabindex

"0"

role

"button"

I'm a div

</div> Semantics ma ) er  <button> Just use button </button>

There’s more…

Who are we making this for? https://www.microsoft.com/en-us/design/inclusive

T WEETABLE TAKE-AWAY Assuming that everybody is able to see, hear, say, and touch all the time creates the potential to ignore a lot of users.

Plugins and best practices • frend.co • inclusive-components.design • heydonworks.com/practical_aria_examples

T WEETABLE TAKE-AWAY Make sure to test JS components for keyboard support before you use them.

the document outline

The Document Outline (h1-h6) • Convey document structure • SEO • Navigation for screen readers

<h1> Heading </h1> <section> <h1> Heading </h1> <section> <h1> Heading </h1> </section> </section> The HTML5 document outline is a myth

<h1> Heading </h1> <section> <h2> Heading </h2> <section> <h3> Heading </h3> </section> </section> Use properly ranked h-elements

T WEETABLE TAKE-AWAY A sound document outline has a huge impact on third party so ( ware. Do your best to g et it right!

<header

role

"banner"

</header> <section> <form

role

"search"

</form>

</section> <aside></aside> <footer

role

"contentinfo"

</footer>

Navigation via landmarks

T WEETABLE TAKE-AWAY Take enough time to think about your document structure and markup content correctly.

T WEETABLE TAKE-AWAY Accessibility is something that concerns all of us, you and me, every day. What we create is useless if it isn’t accessible.

Manuel Matuzovi ć

!

@mmatuzo pitercss 06/2017 THANK YOU medium.com /@matuzo codepen.io/matuzo

manuel@matuzo.at Slides: h

ps://speakerdeck.com/matuzo

Images • h

p://www.daniel.at/images/pictures/_DSF2655.jpg

• h

ps://en.wikipedia.org/wiki/QWERTZ#/media/File:KB_Germany.svg

• h

ps://en.wikipedia.org/wiki/QWERTY#/media/File:KB_Intl_English_Mac_- Apple_Keyboard(MC184Z).svg

• h

ps://upload.wikimedia.org/wikipedia/commons/4/41/Belgian_pc_keyboard.svg

• h

ps://upload.wikimedia.org/wikipedia/commons/6/60/KB_Russian.svg

• h

ps://www.microso " .com/en-us/design/inclusive