Category: design

High Contrast Option for Color Contrast

Most of use are aware of the color contrast guideline in WCAG 2.0 AA which states:

1.4.3 Contrast (Minimum): The visual presentation of text and images of text has a contrast ratio of at least 4.5:1, except for the following: (Level AA)

This can be a big problem for websites when the color scheme uses the brand colors which do not meet the above requirement. This can be especially troublesome for medium orange and green tones.

A technique to meet this guideline is G174:

Providing a control with a sufficient contrast ratio that allows users to switch to a presentation that uses sufficient contrast

You may want (or need) to consider this technique for your website, at least temporarily. The control for this option should be in a global nav bar or settings (if available). A longer term goal is to correct your brand’s colors so that it meets the 4.5:1 color contrast requirement.

Here are some examples of websites that have a high contrast option available (the control is in the top horizontal bar in all examples).

partial screen shot of Choice Hotels website; arrows points to text increase contrast
Example of providing an increased contrast setting on a website.

Web Accessibility Books

Here’s a great list of accessibility books. Feel free to submit any others in comments.

Related:

book cover: Accessibility For Everyone book cover: Inclusive Design Patterns book: A Web for Everyone

Color Contrast Tools

Here are some tools that specifically check for color contrast accessibility issues on websites. And a few related links below. Know any others?

More:

color wheel

Infinite Scrolling and Accessibility (It’s Usually Bad)

Experts say don’t do infinite scrolling, or be extremely careful in doing so. I completely agree. Infinite scrolling creates accessibility and usability problems. Below are checkpoints, issues and suggestions from a few resources.

Here’s a great list of checkpoints from the article So You Think You’ve Built a Good Infinite Scroll by Adrian Roselli (@aardrian):

  1. Can the user hit “back” and return to the exact same place?
  2. Is there paging for when the JavaScript breaks?
  3. Does the page have a footer?
  4. Can a keyboard user access all other content on the page?
  5. Can you share a URL to a specific place on the page?
  6. Can a user easily jump ahead a few “pages” to quickly get to content much further down the list?
  7. Does the memory footprint of the page dramatically increase after just a couple new “pages?”
  8. Is there a way to disable automatic infinite scrolling and lean on standard paging?
  9. Have you conducted any user tests?
  10. Are you satisfying a use case that has come from research or user request?
  11. Do you have any analytics/tracking to measure success?

In the article Infinite Scrolling: Let’s Get To The Bottom Of This, Smashing Magazine makes some great points including the following.

Fails: temptation, optimism, exhaustion, pogo-sticking, loss of control, distracting, unreachable

  • Users want immediate access to exclusive data.
  • Users want to feel in control.
  • Users often look for landmarks when scrolling.
  • Consider conventional pagination or a hybrid solution.
  • Provide interesting content without an ambiguous interface.
  • Users often expect a footer.
  • An infinite list is still a list.
  • Effects are nice to have but not a must.

In the Simply Accessible article Automatic infinite scrolling & accessibility, Derek Featherstone (@Feather) says:

  • Just don’t implement infinite scrolling.
  • Replace automatic infinite scrolling with a “Load more results…” button or link that explicitly invites the user to add more. Once they do a few times, prompt them to ask if they’d like to turn auto-loading of more results on.
  • No, really, just don’t implement infinite scrolling.

Further reading:

Layout Tables Tip

It’s 2015, so hopefully web developers know that table elements should not be used for layout. There are many reasons why CSS for layout is better but at the core, HTML tables are data tables; they’ve always been meant for data.

But even today, sometimes a table is used for layout, for whatever reason—time constraints, lack of CSS skills, legacy code, etc.

If a table is used for layout, add ARIA role of presentation to the table element. This will remove the table elements from the Accessibility API which provides for a better user experience for users of assistive technology, particularly screen readers.

Other elements such as caption, summary, and thead should be removed. See the Microsoft resource ARIA Presentation Table Error.

Here’s a code example derived from a W3C example for the use of role=presentation. The following code in the HTML tree:

<table role="presentation">
<tr><td>Foo bar</td><tr>
</table>

Becomes this in the accessibility tree:

<>
<><>Foo bar</></>
</>

Further reading: