Journal

Here’s how I’d handle various common SVG icon scenarios with accessibility in mind.

Just an icon

So this is an icon that’s not within a link or button and has no adjacent text. This might be, for example, an upward-pointing arrow icon in a <td> in a “league table” where the arrow is intended to indicate a trend such as “The figure has increased” or “Moving up the table”.

The point here is that in this scenario the SVG is content rather than decoration.

<svg 
  role="img" 
  focusable="false" 
  aria-labelledby="arrow-title"
>
  <title id="arrow-title">Balance has increased</title>
  <path …>…</path
</svg>

Note: Fizz Studio’s article Reliable valid SVG accessibility suggests that the addition of aria-labelledby pointing to an id for the <title> (as Léonie originally recommended) is no longer necessary. That’s encouraging, but as it does no harm to keep it I think I’ll continue to include it for the moment.

The same article also offers that maybe we should not use the SVG <title> element (and use aria-label to provide an accessible name instead) due to the fact that it leads to a potentially undesirable tooltip, much like the HTML title attribute does. To be honest I’m OK with this and don’t see it as a problem, and as I mention later have heard probably even more problematic things about aria-label so will stick with <title>.

Button (or link) with icon plus text

This is easy. Hide the icon from Assistive Technology using aria-hidden to avoid unnecessary repetition and rely on the text as the accessible name for the button or link.

<button>
  <svg aria-hidden="true" focusable="false" ><!--...--></svg>
  Search
</button>

<a href="/search">
  <svg aria-hidden="true" focusable="false"><!--...--></svg>
  Search
</a>

Button (or link) with icon alone

In this case the design spec is for a button with no accompanying text, therefore we must add the accessible name for Assistive Technologies ourselves.

<button>
  <svg focusable="false" aria-hidden="true"><!--...--></svg>
  <span class="visually-hidden">Search</span>
</button>

<a href="/search">
  <svg focusable="false" aria-hidden="true"><!--...--></svg>
  <span class="visually-hidden">Search</span>
</a>

The reason I use text that’s visually-hidden using CSS for the accessible name rather than adding aria-label on the button or link is because I’ve heard that the former option is more reliable. In greater detail: aria-label is announced inconsistently and not always translated.

References

• Accessible SVG Icons, by Chris Coyier;
• Tips for accessible SVG, by Léonie Watson;
• Reliable, valid SVG accessibility, by Fizz Studio;
• Accessible icon buttons, by Sara Soueidan;
• Every Layout’s Icon component; and
• How to hide elements on a web page, by my bad self.

I’m Jack McDade and I’m tired of boring websites.

So many fun touches in the design for Jack’s personal website! It gave me plenty of chuckles while browsing over the weekend.

My favourite bits were the “Email Deposit Box” on the Radical Design Course section (make sure to have sound turned on) and the entire Design Work page (keep scrolling)!

Here’s Chris Ferdinandi, introducing the ARIA doc-subtitle role.

He sets the scene by describing the popular design pattern where we have a title with a subtitle directly underneath, and that subtitle is set to be visually distinct via its font size being larger than the body text while remaining smaller than the main heading. Developers have typically marked up the subtitle using either another heading element, or a dedicated class. He suggests that the former is bad because headings in HTML are for conveying structure (with the inference that a subtitle is not structural) while the latter is suboptimal because it provides sighted users with additional information that visually impaired users don’t get.

A better approach is coming; the new role=doc-subtitle will convey to screen readers that the element is a subheading.

I’m going to hold off using it for a little bit until screen reader support improves, but generally this feels like a good move.

Here’s a beautiful, magazine style website design for digital publication Bustle. The typography, use of whitespace, responsive layout, menu pattern, colour palette and imagery are all on point!

SVGs enable full-screen hi-res visuals with a file-size near 5KB and are well-supported by all modern browsers. What's not to love?

A neat tool for selecting, customising and applying SVG backgrounds.

(via @css)

Here’s Jeremy Keith, making the moral case for accessible websites and why we shouldn’t use “you can make more money by not turning people away” as an argument:

I understand how it’s useful to have the stats and numbers to hand should you need to convince a sociopath in your organisation, but when numbers are used as the justification, you’re playing the numbers game from then on. You’ll probably have to field questions like ”Well, how many screen reader users are visiting our site anyway?” (To which the correct answer is “I don’t know and I don’t care” – even if the number is 1, the website should still be accessible because it’s the right thing to do.)

(via @adactio)

A font pairing app that helps you match fonts – useful for pairing a webfont with a suitable fallback. You can place the fonts on top of each other, side by side, or in the same line. You can adjust your fallback font’s size and position to get a great match.

If you’re using a web font, you're bound to see a flash of unstyled text (or FOUC), between the initial render of your websafe font and the webfont that you’ve chosen. This usually results in a jarring shift in layout, due to sizing discrepancies between the two fonts. To minimize this discrepancy, you can try to match the fallback font and the intended webfont’s x-heights and widths. This tool helps you do exactly that.

Chris explains how debouncing and throttling are two related but different techniques for improving performance and user experience when working with frequently invoked JavaScript event handlers.

With throttling, you run a function immediately, then wait a specified amount of time before running it again. Any additional attempts to run it before that time period is over are ignored.

With debouncing, after the relevant event fires a specified time period must pass uninterrupted in order for your function to run. When the time period has passed uninterrupted, that last attempt to run the function is the one that runs, with any previous attempts ignored.

You might debounce code in event handlers for scroll events to run when the user is completely done scrolling so as not to negatively affect browser performance and user experience.

For interactions that update the UI, throttling might make more sense, so that the updates run at predictable intervals.

NB I’ve previously found Trey Huffine’s debounce tutorial and example function really useful, too.

BLOKK is a font for quick mock-ups and wireframing for clients who do not understand latin.

A cool idea here, which gives you “block” versions of the words in your lorem ipsum text, at the same width.

However at this point I do need to remind myself that designing and wireframing with real content is always better.