Ire takes a deep dive into implementing an accessible tool tip.
I think Cathy might’ve buried the lede:
The knock on effect of this was removing media queries. As I moved towards some of the more modern features of CSS the need to target specific screen sizes with unique code was removed.
But on the topic of Sass, layout is now taken care of with CSS grid, variables are taken care of with CSS custom properties, and mixins for typography are taken care of with
Personally, I’ve always found the most useful feature of Sass to simply be that you can have lots of separate Sass files that get combined into one CSS file—very handy for component libraries.
A terrific explanation of the
aria-live attribute from Ire. If you’re doing anything with Ajax, this is vital knowledge.
I had to read through this twice, but I think I get it now (I’m not the sharpest knife in the drawer). Very useful if you’re doing theming in CSS.
This is very timely. I’ve been doing some consulting at a company where they are perhaps a little over-reliant on automated accessibility tests.
Automated accessibility tests are a great resource to have, but they can’t automatically make your site accessible. Use them as one step of a larger testing process.
In defence of the cascade (especially now that we’ve got CSS custom properties).
I think embracing CSS’s cascade can be a great way to encourage consistency and simplicity in UIs. Rather than every new component being a free for all, it trains both designers and developers to think in terms of aligning with and re-using what they already have.
Remember, every time you set a property in CSS you are in fact overriding something (even if it’s just the default user agent styles). In other words, CSS code is mostly expressing exceptions to a default design.
A handy bunch of checklists from Dave for creating accessible components. Each component gets a card that lists the expectations for interaction.
I encourage you to think about and make sure you are using the right elements at the right time. Sometimes I overthink this, but that’s because it’s that important to me - I want to make sure that the markup I use helps people understand the content, and doesn’t hinder them.
A great collection of styled and accessible form elements:
Form controls are necessary in many interfaces, but are often considered annoying, if not downright difficult, to style. Many of the markup patterns presented here can serve as a baseline for building more attractive form controls without having to exclude users who may rely on assistive technology to get things done.
Léonie makes a really good point here: if you’re adding
This is a great interview with Rich on all things related to web typography—including, of course, variable fonts.
I’m so lucky that I literally get to work side by side with Rich; I get to geek out with him about font stuff all the time.
A fun way to play around with the options in variable fonts.
A lot of the issues here are with abuses of the
placeholder attribute—using it as a label, using it for additional information, etc.—whereas using it quite literally as a placeholder can be thought of as an enhancement (I almost always preface mine with “e.g.”).
Still, there’s no getting around that terrible colour contrast issue: if the contrast were greater, it would look too much like an actual pre-filled value, and that’s potentially worse.
Mandy’s experiments with text effects in CSS are kinda mindblowing—I can’t wait to see her at Ampersand at the end of the month!
A nice intro to variable fonts.
When to use
aria-hidden="true", and when you might need
aria-hiddenby itself is not enough to completely hide an element from all users, if that is the end goal.
When to use
aria-hiddencan be used to completely hide content from assistive technology, modifying an element’s
roleto “none” or “presentation” removes the semantics of the element, but does not hide the content from assistive technologies.