Designing accessible components

Designing accessibility? Other developers? What?

Today we're talking about:

• Component libraries
• Diverse models of user interaction
• Diverse models of developer meddling

OK but... why do I care?

Accessibility is:

• Freedom
• Privacy
• Participation
• Equality

The Curb Cut effect

• Curb cuts
• Audio captions and transcripts
• High contrast mode or night mode
• Distraction-free features
• An accessible, semantic web?

OK, accessibility. But why make a pattern library?

Meet your coworkers

“If it looks right, I'm done.”

“What's an ARIA? I don't like opera.”

“I need these twenty obscure features, and a pony.”

An icon button case study:

An icon button in the wild

							<button ng-click="triggerDownload()" class="btn"
							  tooltip="Download as a zip file">
							  <i class="icon-download-alt"></i>
							</button>
						

							<button type="button">I'm a button!</button>
						

							<button type="submit">
							  Search
							  <svg role="img" aria-hidden="true">
							    <use xlink:href="#search"></use>
							  </svg>
							</button>
						

							<button type="submit">
							  <svg role="img" aria-labelledby="search-title">
							    <title id="search-title">Search</title>
							    <use xlink:href="#search"></use>
							  </svg>
							</button>
						

Other possibilities:

• aria-label
• icon fonts
• a text node with some fancy .sr-only CSS

None of this is easy!

Reserving control:

							interface ButtonProperties {
							  type: 'submit' | 'reset' | 'button';
							}

							interface IconProperties {
								use: string;
								label?: string;
							}
						

Ponies, popups, oh my!

Dance with ponies

What could go wrong?

Common button use cases:

• Submit or reset a form

  type="submit | reset"

• Open a panel

  aria-expanded="true"

• Open a menu

  aria-haspopup="menu"

• Toggle a state

  aria-pressed="true"

Uncommon button use cases

???

Who really knows best?

With too many granular details left open-ended...

... you end up with this:

							<button aria-haspopup="true" class="btn btn-popup">
							  Tooltip
							  <svg role="img">
							    <use xlink:href="#plus"></use>
							  </svg>
							</button>
						

or this:

							<button aria-pressed="true" aria-expanded="true"
							  class="btn btn-open btn-pressed">
							  Open Accordion
							  <svg role="img" aria-labelledby="icon-title">
							    <title id="icon-title">Expand accordion</title>
							    <use xlink:href="#plus"></use>
							  </svg>
							</button>
						

But without enough flexibility, your component might be abandoned in favor of this:

							<div role="button" onclick="ponyDance()">
							  Ponies for all
							  <img src="pony.png">
							</div>
						

Build extensibility into:

• Visual styles
• Layout
• Child content

Provide an intuitive API for built-in defaults:

							interface ButtonProperties {
							  type: 'submit' | 'reset' | 'button' | 'toggle'
							        | 'menu' | 'accordion';
							  disabled: boolean;
							  pressed: boolean;
							  open: boolean;
							}
						

Where should you keep control?

• Accessibility
• Internationalization
• Performance
• ...

Choosing what to build

Are these both menus?

Don't ask

What it looks like

ask

What it does

Try describing your component's function in a single sentence:

The limits of a framework

You will never be able to:

• Write appropriate labels and alt text
• Take care of overall page structure (landmarks, heading hierarchy, focus order)
• Account for all possible use cases

Instead:

• Be realistic up front
• Provide good usage documentation
• Educate other developers about diverse interaction patterns