This is just a lonely piece of text that says “accessibility?” Tragic, really. To make this even begin to work correctly again, we need to add all sorts of remedial WAI-ARIA semantics. In the immortal words of Iron Maiden, “can I play with madness?”

[code language="html"]

accessibility?

[/code]

Our example is still one hundred percent inaccessible because we have yet to cludge all of the conventional behaviors and key bindings established by the standard type="radio". This will require the tabindex attribute and JavaScript galore — and do you know what? I’m not even going to begin down that road.

What I have done is available as a CodePen demo, and to follow is an explanation of the technique.

Note: If you’ve not used radio buttons with a keyboard before, know that you are able to focus the active button using the TAB key and change the active button using the UP and DOWN arrow keys. This is standard UA behavior, not a JavaScript emulation.

Use what’s already there

To think accessibly, you need to consider the HTML the interface and the CSS merely the appearance of that interface; the branding. Accordingly, we need to look for ways to seize control of UI aesthetics without relying on the recreation of the underlying markup that marks a departure from standards.

What do we know about radio buttons?

One thing we know about radio buttons is that they can be in either a checked or unchecked state. Never mind ARIA, this is just HTML’s checked attribute.

[code language="html"]
accessible

pretty

accessible and pretty

[/code]

Fortuitously, we can express the checked state via the :checked pseudo-class in CSS:

Unfortunately, actually ‘subsetting’ a font (reducing its intrinsic character set to just those characters you wish to render) requires the use of font design software that is one of eye-wateringly expensive, not available on your platform or liable to fill your swearing quota within moments of the wretched thing’s installation.

Until now. Thanks to “one weird trick” I discovered using Google Fonts, I can now offer you a way to be inventive with subsets without the need to deconstruct those fonts manually. It’s all about Google Fonts’ URL text parameter.

J A V A S C R I P T

No, JavaScript is not required to achieve this (I wouldn’t do that to you). I’m talking about the stringjavascript. For the redesign of the Neontribe website, I decided to use the burgeoningly popular Ghost blogging platform, which is built on JavaScript. Since I’m a bit of a wag, I thought it would be fun to advertise this fact rendering the term ‘JavaScript’ in a ghoulish font. You see?

Now, I appreciate this isn’t a very good joke — if you can even call it a joke. What would make it even less funny, though, would be if I were to fetch a whole 150-or-more-characters font just for this discreet instance of typographical whimsy.

Instead, I did this:

[code language="html"]
[/code]

Note the aforementioned text parameter. This tells Google Fonts that you’re only interested in the supplied set of characters. It prompts Google to dynamically build a subsetted version of the Creepster font and send it to me. Note the kit parameter below.

]]>https://www.sitepoint.com/joy-of-subsets-web-fonts/feed/20Learning to focus()https://www.sitepoint.com/learning-to-focus/
https://www.sitepoint.com/learning-to-focus/#commentsThu, 17 Apr 2014 18:00:53 +0000http://www.sitepoint.com/?p=79827Thanks to good fortune, I have a functional pair of eyes. When it comes to traversing web pages, this is something of a boon since shifting my focus from one part of the page to another requires nothing more than semi-consciously contracting my extraocular muscles and rotating my eyeballs a fraction of their circumference.

Though my visual — and, therefore, cognitive — focus could now be said to have changed, the user interface itself does not know my attention has turned. At least, not until I begin to physically interact with the newly scrutinized region. To put it another way, rotating my eyeballs is an unrecorded event.

Herein lies a very common but frequently unaddressed accessibility issue: If I’m not using my eyes (and my mouse hand to point), how do I ‘focus’ on something in order to then interact with it? The answer, as I’m sure you know, is via programmatic focus. It’s not as simple as just incorporating ‘focusable’ elements into our designs, however. Sometimes it is not the user but the interface on the user’s behalf that must move focus between different areas. This requires deliberate focus management on the part of the developer.

For accessibility, managing focus is essential in many of even the simplest JavaScript-driven interactive widgets, but correct usage is almost impossible to test for with automated QA tools. That’s why I want to take you through a couple of simple examples today.

ScrollTop Animation

In this example, I invite you to imagine you have ‘enhanced’ a same-page navigation link so that, instead of jumping abruptly to the link’s target fragment (#section1, let’s say), you are ushered gently to this destination via a JavaScript scrollTop animation. The important thing to note regarding accessibility when using this technique is the necessity to override the default function of the <a> element.

[code language="javascript"]
event.preventDefault();
[/code]

By doing this you are telling the browser to avoid, at all costs, doing anything standard, expected or interoperable. You are telling the link not to link. In fact, the only way to make certain the link actually takes the user correctly to the page fragment is to turn JavaScript off. Well, then.

By simply linking to a page fragment — as one would with JavaScript off — the browser essentially focuses this fragment. This is where screen reader output and keyboard interaction is now based. By animating the scrollTop, no such focusing action takes place, meaning screen reader output and keyboard interaction continues from the area of the page that is no longer in view. This is no good.