Accessibility The Crafting of a Friendlier and More Considerate Web

Why It Matters

What We'll Cover

• The Standards
• Accessibility Considerations Throughout A Project
  • Design: Text and Graphical Elements
  • Development: Components and Attributes
  • Testing: Tools and Resources

The Standards

WCAG 2.0

WCAG 2.0 is the second iteration of the standards written by the W3C to outline elements of structure that make websites accessible.

What are the standards?

The overarching goal is to make sure that your pages are

• Perceivable
• Operable
• Understandable
• Robust

The Design Phase

Design: Typeface

Select typefaces that are readable for a wide variety of users, including those with low-vision and dyslexia.

• Longer ascenders and descenders to make different letterforms more distinct from each other.
• No ornamentation that obscures the letterforms.

Design: Typeface

Select typefaces that are readable for a wide variety of users, including those with low-vision and dyslexia.

• Letterforms that are distinct from others that are formed in a similar way.
• Letterforms with generous counters also have an edge in readability for low-vision users.

Design: Typeface

Additionally, a study performed in 2013 using system fonts and a font designed specifically for dyslexics found a reading preference for sans-serif typefaces (favoring Humanist-style), though reading speed was pretty even across your usual suspects of non-florid fonts. (Verdana, Helvetica, Arial, Courier, Times New Roman, etc.) Also, don't set large sweeps of copy in italic unless you're a monster and you want people to be unhappy.

Design: Typeface

If you'd like to do some guerilla simulation of low-vision on sweeps of text, you can try applying a style of filter: blur(3px); to the relevant text and then make determinations on font and style. Adjust the blur to taste.

The next slide has an example of the effect used on Google Fonts.

Design: Type Size

Sometimes, in spite of your best efforts, users will have to zoom in to be able to read your page comfortably.

Design: Type Size

Embrace the relative! Set font-size, padding, and margin to relative units (rem, em, ch) to make it possible to zoom gracefully! (View WCAG SC 1.4.4)

Design: Text

• Keep fields of text text-align: left;
• For paragraphs, keep line-height: 1.5;
• Bonus: Paragraphs between 45–75 characters long are most comfortable for reading, so consider sizing your text blocks with the respective rem units. (View WCAG SC 1.4.8)

Design: Links

When possible, make it explicit what kind of content a link links to reduce cognitive load on the user. (View WCAG SC 2.4.9)

If for some reason, it can't be done, that's fine — so long as all users are left with a sense of mystery, this criteria still counts as passed.

Design: Links

• At the very least, context should hint at where a link might be taking the user. (View WCAG SC 2.4.4)
• To make this easier for assistive technologies, use the aria-label attribute to provide more information about where a link might take you or point at information that does describe a link using aria-labelledby

Design: Links

Text links are also best displayed underlined to be distiguishable from normal copy for colorblind users.
(View WCAG 1.4.1)

Design: Links

As a bonus, here's a spin on the text-underline that also keeps decenders in the link text from becoming obscured:

a {
	color: #2d43d0 ;
	text-decoration: none;
	text-shadow: 0.05em 0 0 #fafafa, -0.05em 0 0 #fafafa,
	0 0.05em 0 #fafafa, 0 -0.05em 0 #fafafa,
	0.1em 0 0 #fafafa, -0.1em 0 0 #fafafa,
	0 0.1em 0 #fafafa, 0 -0.1em 0 #fafafa;
	background-image: linear-gradient(to right, currentColor
	0%, currentColor 100%);
	background-repeat: repeat-x;
	background-position: bottom 0.05em center;
	background-size: 100% 0.1em;
}

Design: Color

As a baseline, be sure that the contrast ratio between the background and text is at least 4.5 for all text and at least 3 for text that's above 14pt and bold or above 18pt in size. This should guarantee readability for users with 20/40 vision (View WCAG SC 1.4.3)

Design: Color

To take it to the next level and be a hero to people with 20/80 vision, you can aim for a contrast ratio of 7 for your copy. (View WCAG SC 1.4.6)

Design: Color

Any information imparted by charts or graphs by the use of color should be made available in another way for folks with varying types of colorblindness. (View WCAG 1.4.1)

Design: Color

Here's a nice example in the wild for how Trello accommodates for colorblindness in its card labels.

Design: Color

Here are some nice tools to keep yourself honest.

• Contrast-Ratio: A handy tool for spot-testing text and background contrast.
• Color Oracle: A desktop plugin to simulate different types of colorblindness.

Design: Images

If there's alt text, (or <title> text for svgs) it will be read by screen readers.

If there's no alt text, screen readers will have no choice but to read the entirety of the <img src>.

Let's see it in action in the wild.

Design: Images

As a rule of thumb for alt/<title> text...

• INCLUDE when the image is a substitute for text.
• INCLUDE when a description of the image provides additional information.
• OMIT when the image only reinforces existing text.

Design: Images

This is all assuming that your images render — what if connection speeds are dismal?

Design: Images

• Compress your raster images! ImageOptim or Compressor.io can be handy here.
• Selectively load images based on the device being used using <picture>. (View Documentation)
• Use SVG where possible for small file sizes.

Design: Images of Text

• Logos are permissible when augmented with alt text, but any other manifestations of image-based text should be strictly decorative. (View WGAC SC 1.4.5) (View WGAC SC 1.4.9)
• Believe in yourself! You don't need an image for that type treatment! View some sweet typographic samples for inspiration.

Design: Animations

Be sure not to let any animations on your page flash more than three times per second — any faster is a risk for users prone to seizures. (View WCAG SC 2.3.2)

The Development Phase

Development: Head First

• Make sure you use the lang attribute in your html tag for proper reading and text rendering. (View WGAC SC 3.1.1)(View WGAC SC 3.1.2)
• Use <title> tags that describe the content at a glance. (View WCAG SC 2.4.2)

Development: Head First

• Use critical path CSS to prevent any background-images from causing load havoc.
• FOUT (Flash of Unstyled Text) is superior to FOIT (Flash of Invisible Text)!

Development: Markup Order

As your page reads from the top down, so should your markup. This ensures assistive technologies and keyboard users will be able to digest and navigate information in the same sequence as other users. (View WCAG SC 2.4.3)

Development: Keeping It Semantic

When possible, use semantically-appropriate HTML tags for your content.

Development: Headers

Conveniently and very self-evidently, <header> tags should be used for headers.

Attach the attribute of role="banner" to your primary header.

Development: Navigation

• You don't have to reinvent the wheel — adhering to layout conventions common on the web allow you to piggyback on their existing familiarity.
• Keep page navigation and controls in the same location as often as possible! This helps users familiarize themselves with the layout and anticipate where they'll find the content they seek in the future. (View WCAG SC 3.2.3)

Development: Navigation

Just like the with <header>, there are handy <nav> tags to serve this purpose.

• Attach the attribute of role="navigation" for navigational, but non-<nav> elements.
• Use the WAI-ARIA attribute of aria-label or reference a navigational area's header with aria-labelledby to make its purpose clear

Development: Navigation

Making search functionality available also provides a nice bump to accessibility and provides opportunities to navigate across pages in the normal flow outside of the main navigational fixtures. (View WCAG SC 2.4.5)

Development: Navigation

When possible, keep it clear where the user is currently located, whether by providing a visual indicator within the site's navigation or providing breadcrumbs marking their path.
(View WCAG SC 2.4.8)

Development: Navigation

For touch-based devices, aim for a minimum of 44px × 44px (if you believe Apple) or 48px × 48px (if you believe Google).

This should allow most folks to select an element on the screen without obscuring the content and possibly misselecting.

Development: Navigation

When utilizing dropdown or slide-out navigation, use role and aria attributes to prevent a complete readout of submenus and keep from "losing" focus. (View WCAG SC 2.4.1)

Development: Navigation

(Source CodePen)
(What Makes a Dropdown Count as Accessible)

Development: Navigation

Speaking of :focus, leave that blue halo serving as a focus indicator alone unless you're replacing it with something else! (View WCAG SC 2.4.7)

Development: Navigation

• To add a non-link or form element to the tab flow, add the attribute tabindex="0" to the element.
• If you want to take an tabbable item and prevent it from appearing in the order by default to apply other behavior, use the tabindex="-1" attribute.

It's also not enough to make sure that everything's focusable for keyboards, flow also needs to be considered. (An Example)

Development: Navigation

To prevent a full read-out of navigation or forcing a keyboard user to tab through it again on a page load, provide a "Skip to Content Link" in your header before the <nav> that's only visible to the user on :focus.

Development: Navigation

  skip to main content

  
Site Name

  

(Example of Functionality)

Development: Navigation

Stay vigilant against keyboard traps whenever bucking default element behavior and prescribing something new with JavaScript!

Development: Main

Use the <main> tags for your primary content area, as well as the role="main" landmark as an attribute.

Development: Headings

When content is broken into sections, be sure to make headings as descriptive of the content as possible and use them in sequence (i.e. h1..h6) to make content more digestable and navigable. (View WCAG SC 2.4.10)

Development: Forms

When constructing forms, be sure that all of your form fields have labels that they're associated to. (View WCAG SC 2.4.6)

First name (required):

Development: Forms

Don't depend on placeholder text as a label replacement. It can provide context as to what belongs in a form field, but once a user begins to type in it, that context is lost and unrecoverable for purposes of form review.

Development: Communicating State

• Mark elements that are hidden within the interface with the aria-hidden="true" attribute and toggle its state to false with JavaScript when it changes.
• If elements contain a submenu, aria-haspopup="true" will communicate this to assistive technology. Likewise, aria-expanded="true" will indicate whether or not an expanding element is open.

Development: State & Properties

• For users to keep the best grasp on context, make redirects, where they occur, as instantaneous as possible.
• Only allow the page to refresh upon being triggered by the user to keep page transitions expected (View WCAG SC 3.2.5)
• In cases where user sessions time out, be kind and take the user back to where they left off to prevent disorientation.

Development: Not-So-Secret Text

For elements that act as visual dividers, the role="presentation" can be used to get screenreaders to ignore it.

Development: Not-So-Secret Text

For non-sighted users who need additional context provided for other users via images or CSS, provide content that will be picked up by screen readers but "invisible" to other users with this utility class:

.visually-hidden { // For screenreaders, not sighted users
	position: absolute;
	width: 1px;
	height: 1px;
	overflow: hidden;
	clip: rect(1px, 1px, 1px, 1px);
}

Additional Topics

• Audio Use
• Video
• Time-Based Interaction
• WAI-ARIA Properties

Additional Tools & Resources

• Google Accessibility Tools: Handy library for accessibility-related testing
• tota11y: Khan Academy's plug-and-play accessibility auditing tool
• Inclusive Design Patterns by Heydon Pickering: Handy book to explore and implement accessible (and generally inclusive) user experiences.

Additional Tools & Resources

• WebAIM: Accessibility articles, checklists, and all-important screenreader operation assistance.
• The A11Y Project: Handy explanations, patterns, and checklists for accessibility success criteria.
• 18F Accessibility Guide: A nice outline of what and what not to do with your sites to keep them accessible.

Questions?

Thank you!