Better Typography with Font Variants - Jonathan Harrell | CSS Blogger & Teacher, UI/UX Designer, Front-End Developer
A quick guide to all the
font-variant-... stuff in CSS.
A quick guide to all the
font-variant-... stuff in CSS.
Paul walks us through the process of making some incremental accessibility improvements to this year’s 24 Ways.
Creating something new will always attract attention and admiration, but there’s an under-celebrated nobility in improving what already exists. While not all changes may be visual, they can have just as much impact.
These experiments with transitioning variable font styles on hover might be silly, but I can see the potential for some beautiful interaction design.
The latest edition of Heydon’s Inclusive Components is absolutely fantastic! The pattern itself—toggling sections of content—is quite straightforward, but then there’s a masterclass in how to create a web component that still allows the content to be accessible in older browsers. The key, as ever, is progressive enhancement:
Whether implemented through web components or not, progressive enhancement not only ensures the interface is well-structured and robust. As we’ve seen here, it can also simplify the editorial process. This makes developing the application and its content more inclusive.
James has been tweaking the accessibility of his site navigation. I’m looking forward to the sequel.
A good introduction to variable fonts, and an exploration of the possible interface elements we might use to choose our settings: toggles? knobs? sliders? control pads?
Another great deep dive by Heydon into a single interface pattern. This time it’s the tooltip, and its cousin, the toggletip.
There’s some great accessibility advice in here.
Mike examines the real power of CSS custom properties compared to Sass variables—they can change at runtime.
I’m convinced that in almost all cases, responsive design logic should now be contained in variables. There is a strong argument too, that when changing any value, whether in a media query or an element scope, it belongs in a variable. If it changes, it is by definition a variable and this logic should be separated from design.
There are some great hands-on accessibility patterns in this talk transcript from Scott.
Comparing different ways to hide content accessibly:
There are three reasons behind hiding content in an interface, and it’s important to identify what those reasons are, as they will correlate with the appropriate technique needed to hide such content.
- Temporarily Hidden Content
- Purposefully Visually Hidden Content
- Purposefully Visual-Only Content
There’s a lot of great knowledge in here that can be applied to plenty of other interface elements too.
Following on from Ire’s post about linting HTML with CSS, here’s an older post from Ebay about how being specific with your CSS selectors can help avoid inaccessible markup getting into production.
Rich has posted a sneak peek of one part of his book on Ev’s blog.
Here’s one of them new-fangled variable fonts that’re all the rage. And this one’s designed by David Berlow. And it’s free!
aria-current attribute is very handy and easy to implement. Léonie explains it really well here.
Harry demonstrates a really good use for CSS custom properties—allowing users to theme an interface.
This is what Nick Sherman has been banging on about for years, and now the time has come for variable fonts …as long as typographers, browser makers, and standards bodies get behind it.
More details on Ev’s blog.
I wrote a while back about how I switched from using a button to using a link for progressive disclosure patterns. That looks like it was a good move—if I use a button, I’d need to use
aria-controls and, as Heydon outlines here, the screen reader support is pants.
Zoe asked a question on Twitter recently:
#a11y folks: Is it still best to put form field instruction/help text inside the <label>, or is aria-describedby sufficient nowadays?— Zoe M. Gillenwater (@zomigi) August 18, 2016
‘Sfunny—I had been pondering this exact question. In fact, I threw a CodePen together a couple of weeks ago.
Visually, both examples look the same; there’s a label, then a form field, then some extra text (in this case, a validation message).
The first example puts the validation message in an
em element inside the
label text itself, so I know it won’t be missed by a screen reader—I think I first learned this technique from Derek many years ago.
<div class="first error example"> <label for="firstemail">Email <em class="message">must include the @ symbol</em> </label> <input type="email" id="firstemail" placeholder="e.g. email@example.com"> </div>
The second example puts the validation message after the form field, but uses
aria-describedby to explicitly associate that message with the form field—this means the message should be read after the form field.
<div class="second error example"> <label for="secondemail">Email</label> <input type="email" id="secondemail" placeholder="e.g. firstname.lastname@example.org" aria-describedby="seconderror"> <em class="message" id="seconderror">must include the @ symbol</em> </div>
In both cases, the validation message won’t be missed by screen readers, although there’s a slight difference in the order in which things get read out. In the first example we get:
And in the second example we get:
In this particular example, the ordering in the second example more closely matches the visual representation, although I’m not sure how much of a factor that should be in choosing between the options.
Anyway, I was wondering whether one of these two options is “better” or “worse” than the other. I suspect that there isn’t a hard and fast answer.