It’s relatively easy to get lost in all the new features of CSS Grid because there’s just so much to learn and familiarize ourselves with; it’s much easier to learn it chunk by chunk in my opinion.
And so you might already be familiar with Rachel Andrew’s Grid By Example which contains a whole bunch of tutorials with new layout tips and tricks about CSS Grid. But the minmax() tutorial is one small chunk of Grid that you can learn today and thankfully Rachel has made a rather handy two minute long video that dives straight into it.
In fact, it’s pretty darn impressive how many opportunities just one new CSS feature can give us.
HTML has given us loads of form validation stuff in the last few years. Dave Rupert puts a point on the UX problems with it:
If you’ve ever experimented with HTML5 Form Validation, you’ve probably been disappointed. The out-of-box experience isn’t quite what you want. Adding the required attribute to inputs works wonderfully. However the styling portion with input:invalid sorta sucks because empty inputs are trigger the :invalid state, even before the user has interacted with the page.
Fortunately, there is an invalid DOM event that does fire with useful timing: when the form is submitted. Remember this doesn’t buy you super deep browser support though. If you need that, look into polyfilling. I imagine the future of form validation is either HTML/CSS offering better and more controllable UX, or this.
Harry Roberts wrote about design systems and how compromise has to be baked into them from the very start. He argues that we can’t be dictatorial about what is and isn’t permitted because design, whether that’s the design of a product, service or system, is always about compromise.
Harry writes:
Whenever you plan or design a system, you need to build in your own ashtrays—a codified way of dealing with the inevitability of somebody doing the wrong thing. Think of what your ideal scenario is—how do you want people to use whatever you’re building—and then try to identify any aspects of it which may be overly opinionated, prescriptive, or restrictive. Then try to preempt how people might try to avoid or circumvent these rules, and work back from there until you can design a safe middle-ground into your framework that can accept these deviations in the safest, least destructive way possible.
The Wix dev team throws their hat into the CSS preprocessor ring:
Stylable is a CSS preprocessor that enables you to write reusable, highly-performant, styled components. Each component exposes a style API that maps its internal parts so you can reuse components across teams without sacrificing stylability.
Scopes styles to components so they don’t “leak” and clash with other styles.
Enables custom pseudo-classes and pseudo-elements that abstract the internal structure of a component. These can then be styled externally.
Uses themes so you can apply different look and feel across your web application.
At build time, the preprocessor converts the Stylable CSS into flat, static, valid, vanilla CSS that works cross-browser.
Looks like Sass luminary Chris Eppstein is getting in on the game of scoped styles with the not-yet-released CSS Blocks. And think of Vue’s support for <style scoped>, and the popularity of utility libraries. I think scoped styles might be the hottest CSS topic in 2018.
Accessibility is a hot topic these days, and the older we web-makers get, the hotter it’s going to become! That might be a snarky outlook, but what I’m trying to say is that it’s about time we start designing the web for everyone because the web was meant to be for everyone, and less and less are we able to predict where, when, and how our work will be consumed.
Accessibility is not just up to developers
As developers, we often encounter accessibility post-design, when we do things like implementating the correct role and aria attributes, ensuring navigation is keyboard friendly, and responsibly hiding elements. In general, our accessibility efforts go towards thinking about how to make specific components and features accessible, such as an SVG icon system or helpful tool-tips.
Given our roles as developers, this makes sense. Accessibility flaws, however, often originate in the UI design itself, and depending on our work environment, we developers don’t necessarily have the authority or bandwidth to advocate for accessibility in the designs we are handed.
For example, let’s say you are tasked with turning a Sketch file into a one-page WordPress site.
The design has finally been approved by the client, and now you have a weekend to build the thing, plus another two days to work with QA to perfect it. As you take a look at the design for the first time, you notice that, on small devices, the dainty serif typeface overlaid on a background image would be difficult for low-sighted visitors to read.
You, the accessibility-minded developer, could proceed in a few ways:
Remain silent and sate your accessibility conscience by making accessible choices in the code where you can
Go ahead and make accessibility improvements to the UI as you develop, present them in the finished product, and explain yourself after
Compile a list of suggested changes to send to the designer and request they be implemented in the mockups so you can then develop them
I was in a situation like this recently and, judge me if you will, I chose number one.
If I’d had the time and the guts, number 2 would’ve gotten me the furthest, but given the nature of my role as a first-time contractor at this high-speed agency I was hoping to develop a working relationship with, I felt I’d be overstepping my bounds and wasn’t ready to take the risk of being too vocal out of the gate. I chose not to do number 3 for similar reasons, mainly for fear of causing more work and stress for the already extremely busy designer.
Now that I have the benefit of hindsight, however, might I add a fourth item to the list?
Send a succinct list of non-technical accessibility tips for UI design to everyone on the team so they make more accessible design choices in future
Where to find such a list? Well, you are in luck! Read on!
Non-technical Accessibility Tips for UI Design
What follows is a list of plain language, no-jargon, „Accessibility Tips for UI Design” you, developer, can share with everyone at work: UI designers, content providers, project managers, and clients alike. The more we can spread awareness about accessibility and think critically about the mockups we are handed to implement, the more accessible the web will be!
I have chosen the examples below from various trendywebsitefeeds, and I used the fantastic Funkify Chrome Extension to simulate the viewing experience of site visitors with varying abilities and disabilities.
First up:
Easy on the animations.
With great power comes great responsibility. The modern web affords us the power to bounce-in, fly-in, or drop-in any content we please, but besides the wow factor, how are these animations contributing to a reader’s experience on your site? How are the animations triggered? Can they be mistakenly triggered, causing a confusing jolt in the flow of your site visitor’s experience?
Take this example of a car repair company’s website. I’ve applied the „Elderly Ellen” filter from Funkify to simulate slightly blurred vision and shaky hands:
Elderly Ellen’s trembling hands cause a jarring experience with bold animations.
If I were Ellen, this experience would likely steer me away from Service King’s services! Someone like Elderly Ellen is constantly frustrated with technology. It’s unnecessary to cause her that stress when she’s trying to read about a service for repairing her car after an already traumatizing fender bender.
Make sure background and text colors have enough contrast.
Although that medium grey text looks just right on that light grey background, it’s hard to read…and impossible to read if you are working out in the sunshine (not a common occurance, but I’ve done it before). Here’s an example of the aforementioned grey-on-grey scenario:
The medium grey text color of these icons’ captions does not contrast enough with the light grey background color.
And now, the same example affected by the „Sunshine Sue” filter from Funkify deems our low contrast captions simply invisible!
And now, simulating sunshine on a screen, the text is completely gone!
The solution? Run your color choices through the WebAIM contrast checker to see if they meet standards for readability and color contrast, and if they don’t, adjust the color values until they do.
The Funkify extension can be used to test anything that is visible in a browser. Even if a design mock isn’t yet implemented in code, an image or PDF can be opened in the browser and the extension will still work!
Be very careful when overlaying text on images, or don’t.
It might look just right to have that dainty serif overlaid on the big header image, but can you read it if you slightly blur your vision? If not, up the contrast between the text and image, perhaps by brightening the text color and increasing the transparency of the image on a dark background.
On Burberry’s website, for example, the user must select from a drop-down in order to enter the site, but the text identifying the drop-down is barely readable over top the background image. There are many ways to solve this from a design standpoint, but for a quick example, we could add a dark background beneath the light text to provide a bit more contrast:
Adding a contrasting background beneath the text overlaid on an image can help with readability.
Similarly, while the delicate descriptive text below the image on Tesla’s new Semi website is delicate and beautiful, it is barely legiible when simulating slightly blurred vision with „Blurry Bianca”:
The descriptive text overlaid on the bottom of this image is barely legible when simulating slightly blurred vision.
Double-check the readability of font weights and sizes.
The thinner the font weight and the smaller the size, the harder it is to read. Even I, as a hearing, well-sighted individual, find myself zooming in on body text at times because it is so darn lightweight and small, even if the color contrast is up to speed. If you must stick with the lightweight font, increasing the sizes and line height can do wonders as well.
I like to ask myself, does it pass the slightly-cross-eye test? That is when I slightly cross my eyes, can I still make out the text?
Some contrast, line-height, and font-size adjustments make for a more readable text in a disclaimer we are supposed to read.
Indicate external links.
If it is a requirement for a link to open in a new tab, first question whether it should be a requirement, then indicate it visually with a small icon or note in the UI.
Additionally, designers can make a note in their designs where there should be screen-reader-only text indicating the link will navigate the user away from their current viewing portal. This was brought to mind by way of some excellent replies to a Twitter conversation; read through that here.
Differentiate between action-oriented social media links vs. profile links.
When we see small social media icons, I think the general assumption is that they link to the relevant social media profiles. Sometimes, however, these icons are actually actions that, rather than linking to a profile, open a „New Tweet” dialog or similar. These actions should be marked as such.
Don’t rely 100% on icons and colors to communicate.
It’s easy to assume everyone knows that a hamburger icon indicates a menu or that everyone is familiar with the various versions of LinkedIn’s icon. However, this is not the case, and it causes a moment of confusion and insult that isn’t necessary to site visitors that are less in-the-know than we are. Especially if your audience tends to be older and/or less tech-savvy, make sure you aren’t relying on what you think is common knowledge.
Reliance on colors for meaning causes a similar issue, and more-so for any users that deal with color blindness. A recent Smashing Magazine article covers this problem in detail and uses the example of a color picker on shoe sales website that, for color-blind users, results in an entirely different palette.
What would the design look like without interactivity?
If all a user could do was scroll, does the content still make sense? Are there areas where, rather than hiding the thumbnail caption under a fancy hover event, the caption could be plainly visible instead? What about on a touch screen, where hover events are treated quite differently?
What else?
Have you encountered issues with accessibility in designs you’ve implemented? How did you handle it? What other tips can we give designers and producers for creating more accessible UI designs?
The first step to advocating for accessible UI design is to simply think twice about what you, the developer, are told to implement. While coding up a design, try applying a few of these Funkify filters and see what results they yield. Think critically about the designs you are handed, and start a conversation with your coworkers.
Color is pretty good for separating things. That’s what your basic pie chart is, isn’t it? You tell the slices apart by color. With enough color contrast, you might be OK, but you might be even better off (particularly where accessibility is concerned) using patterns, or a combination.
Filling a pie slice with a pattern is not a common charting library feature (yet), but if your library of choice is SVG-based, you are free to implement SVG patterns.
You can use the patterns.css file that contains all the current patterns. That will only work for non-SVG elements.
You can use individual patterns, but copying them from the sample pages. CSS class definitions can be found here and SVG pattern defs can be found here
You can add your own patterns or modify mine! The conversion process from SVG document to pattern is very tedious. The purpose of the pattern fills toolchain is to simplify this process. You can clone the repo, run npm install and grunt dev to get a local server going. After that, any changes or additions to the src/patterns/**/* files will be automatically picked up and will re-render the CSS file and the sample pages. If you make new patterns, send them over in a pull request!
Here’s me applying them to SVG elements (but could just as easily be applied to HTML elements):
The topic of disabling links popped up at my work the other day. Somehow, a „disabled” anchor style was added to our typography styles last year when I wasn’t looking. There is a problem though: there is no real way to disable an <a> link (with a valid href attribute) in HTML. Not to mention, why would you even want to? Links are the basis of the web.
At a certain point, it looked like my co-workers were not going to accept this fact, so I started thinking of how this could be accomplished. Knowing that it would take a lot, I wanted to prove that it was not worth the effort and code to support such an unconventional interaction, but I feared that by showing it could be done they would ignore all my warnings and just use my example as proof that it was OK. This hasn’t quite shaken out for me yet, but I figured we could go through my research.
First, things first:
Just don’t do it.
A disabled link is not a link, it’s just text. You need to rethink your design if it calls for disabling a link.
Bootstrap has examples of applying the .disabled class to anchor tags, and I hate them for it. At least they mention that the class only provides a disabled style, but this is misleading. You need to do more than just make a link look disabled if you really want to disable it.
Surefire way: remove the href
If you have decided that you are going to ignore my warning and proceed with disabling a link, then removing the href attribute is the best way I know how.
This attribute may be omitted (as of HTML5) to create a placeholder link. A placeholder link resembles a traditional hyperlink, but does not lead anywhere.
Here is basic JavaScript code to set and remove the href attribute:
/*
* Use your preferred method of targeting a link
*
* document.getElementById('MyLink');
* document.querySelector('.link-class');
* document.querySelector('[href="https://unfetteredthoughts.net"]');
*/
// "Disable" link by removing the href property
link.href = '';
// Enable link by setting the href property
link.href = 'https://unfetteredthoughts.net';
Styling this via CSS is also pretty straightforward:
a {
/* Disabled link styles */
}
a:link, a:visited { /* or a[href] */
/* Enabled link styles */
}
That’s all you need to do!
That’s not enough, I want something more complex so that I can look smarter!
If you just absolutely have to over-engineer some extreme solution, here are some things to consider. Hopefully, you will take heed and recognize that what I am about to show you is not worth the effort.
First, we need to style our link so that it looks disabled.
Setting color to currentColor should reset the font color back to your normal, non-link text color. I am also setting the mouse cursor to not-allowed to display a nice indicator on hover that the normal action is not allowed. Already, we have left out non-mouse users that can’t hover, mainly touch and keyboard, so they won’t get this indication. Next the opacity is cut to half. According to WCAG, disabled elements do not need to meet color contrast guidelines. I think this is very risky since it’s basically plain text at this point, and dropping the opacity in half would make it very hard to read for users with low-vision, another reason I hate this. Lastly, the text decoration underline is removed as this is usually the best indicator something is a link. Now this looks like a disabled link!
But it’s not really disabled! A user can still click/tap on this link. I hear you screaming about pointer-events.
.isDisabled {
...
pointer-events: none;
}
Ok, we are done! Disabled link accomplished! Except, it’s only really disabled for mouse users clicking and touch users tapping. What about browsers that don’t support pointer-events? According to caniuse, this is not supported for Opera Mini and IE<11. IE11 and Edge actually don't support pointer-events unless display is set to block or inline-block. Also, setting pointer-events to none overwrites our nice not-allowed cursor, so now mouse users will not get that additional visual indication that the link is disabled. This is already starting to fall apart. Now we have to change our markup and CSS…
.isDisabled {
cursor: not-allowed;
opacity: 0.5;
}
.isDisabled > a {
color: currentColor;
display: inline-block; /* For IE11/ MS Edge bug */
pointer-events: none;
text-decoration: none;
}
Wrapping the link in a <span> and adding the isDisabled class gives us half of our disabled visual style. A nice side-affect here is that the disabled class is now generic and can be used on other elements, like buttons and form elements. The actual anchor tag now has the pointer-events and text-decoration set to none.
What about keyboard users? Keyboard users will use the ENTER key to activate links. pointer-events are only for pointers, there is no keyboard-events. We also need to prevent activation for older browsers that don’t support pointer-events. Now we have to introduce some JavaScript.
Bring in the JavaScript
// After using preferred method to target link
link.addEventListener('click', function (event) {
if (this.parentElement.classList.contains('isDisabled')) {
event.preventDefault();
}
});
Now our link looks disabled and does not respond to activation via clicks, taps, and the ENTER key. But we are still not done! Screen reader users have no way of knowing that this link is disabled. We need to describe this link as being disabled. The disabled attribute is not valid on links, but we can use aria-disabled="true".
Now I am going to take this opportunity to style the link based on the aria-disabled attribute. I like using ARIA attributes as hooks for CSS because having improperly styled elements is an indicator that important accessibility is missing.
Now our links look disabled, act disabled, and are described as disabled.
Unfortunately, even though the link is described as disabled, some screen readers (JAWS) will still announce this as clickable. It does that for any element that has a click listener. This is because of developer tendency to make non-interactive elements like div and span as pseudo-interactive elements with a simple listener. Nothing we can do about that here. Everything we have done to remove any indication that this is a link is foiled by the assistive technology we were trying to fool, ironically because we have tried to fool it before.
But what if we moved the listener to the body?
document.body.addEventListener('click', function (event) {
// filter out clicks on any other elements
if (event.target.nodeName == 'A' && event.target.getAttribute('aria-disabled') == 'true') {
event.preventDefault();
}
});
Are we done? Well, not really. At some point we will need to enable these links so we need to add additional code that will toggle this state/behavior.
function disableLink(link) {
// 1. Add isDisabled class to parent span
link.parentElement.classList.add('isDisabled');
// 2. Store href so we can add it later
link.setAttribute('data-href', link.href);
// 3. Remove href
link.href = '';
// 4. Set aria-disabled to 'true'
link.setAttribute('aria-disabled', 'true');
}
function enableLink(link) {
// 1. Remove 'isDisabled' class from parent span
link.parentElement.classList.remove('isDisabled');
// 2. Set href
link.href = link.getAttribute('data-href');
// 3. Remove 'aria-disabled', better than setting to false
link.removeAttribute('aria-disabled');
}
That’s it. We now have a disabled link that is visually, functionally, and semantically disabled for all users. It only took 10 lines of CSS, 15 lines of JavaScript (including 1 listener on the body), and 2 HTML elements.
