Design for Performance & Accessibility

When do you think about performance and accessibility?

Many teams optimize performance and add accessibility accommodations in development — after stakeholder sign-off.
At this point, the dev team is on the hook for design decisions which may not optimally balance performance and aesthetics, nor consider the experience for users of assistive technology (AT).

Accessibility & Performance? Really?

In my experience…
Marcy Sutton actually quantified it, in presentations and a blog post. (https://marcysutton.com/accessibility-and-performance/)

Accessibility & Performance? Really?

TL;DR

People rely on keyboards and AT (assistive technology) to interact with the web. At least provide basic accessibility support, before tuning performance. Start there.
Every repaint introduces difficulty for accessibility…
and a performance hit.
The longer it takes to load and render a site, the delay is even greater for AT users, so optimize assets.

Accessibility & Performance? Really?

Bonus: it’s more efficient and cost-effective to have accessibility figured out before development or launch, opposed to hacking add-ons or addressing a lawsuit.

A great experience is performant, usable, and ought to be so for all.

Shift Left: Prioritize Performance & Accessibility from the Start

graphic showing five stages of a project process, idea, design, development, QA, and launch - with performance and accessibility as priorities in design phase

Business requirements include performance and accessibility
Indicate metrics for launch (https://timkadlec.com/2014/11/performance-budget-metrics/)
Document a performance budget http://danielmall.com/articles/how-to-make-a-performance-budget/
Design experience with performance and accessibility as priorities

Shift Left: A Process

This talk outlines a design process prioritizing performance and accessibility from the beginning of your project, including:

“Design in the browser” methodology
QA for accessibility and performance throughout
Specs provided for design and accessibility
Test constantly — can’t stress this enough

Shift Left: Getting Started

“Design in the browser” methodology

Semantic hierarchy for content

<h1>First Level Heading</h1>
 <h2>Second Level Heading</h2>
  <p>Admittedly, a simplistic example.</p>

Shift Left: Getting Started

“Design in the browser” methodology

Include accessibility in the code
(within designer’s ability — always keep learning)

<form>
 <label for="sample">Label</label>
 <input type="text" id="sample" name="sample" />
</form>

Native elements for interaction
Label

Shift Left: Getting Started

QA for accessibility and performance throughout

Validate design using accessibility tools
Weigh the aesthetic and performance value
Test constantly, on many devices, using a variety of connections
Use tools to evaluate design decision impact

Shift Left: Testing Tools

WebPagetest https://www.webpagetest.org/
YSlow http://yslow.org/
Google PageSpeed Insights https://developers.google.com/speed/pagespeed/insights/
Developer Tools https://developer.chrome.com/devtools
W3C Validator https://validator.w3.org/

Shift Left: Accessibility Resources

WCAG Checklist
Disability Considerations
User Stories

Shift Left: Accessibility Resources

WebAIM Color Contrast Checker http://webaim.org/resources/contrastchecker/
WAVE Web Accessibility Tool http://wave.webaim.org/
Color Oracle http://colororacle.org/, color blindness emulator
Voiceover (Mac operating system standard) or NVDA (PC http://www.nvaccess.org/)
Deque’s aXe, probably better for devs https://www.deque.com/products/axe/

Shift Left: Deliverables

Responsive Prototype in HTML/CSS/JS [sample #1, sample #2] If time permits, show the testing tools for speed, a11y, etc.
Red line design specs
Blue line accessibility specs