Accessibility is often solely discussed in terms of people with disabilities. It is also quickly dismissed by smaller companies and startups because they argue that they don't have time and resources to consider this group. via Pocket

"The HTML of a modern app is mostly a div soup. CSS by itself does not offer any structured model at all. High-level JavaScript components use abstractions that are not consistently tied to styles or markup. At the UX level, interfaces are described in terms that have nothing in common with technical implementations. Enter BEM, a unified semantic model for markup, styles, code and UX. "
"Not all blocks have elements."
"One DOM node may host several blocks. A node may be an element within one block and (at the same time) a container for another block."
"Once the designer is familiar with BEM’s terms, they can iterate towards designing blocks and elements, instead of “screens.” This will also help them to identify similar UI parts and unify them."

SVG1.1 accessibility support is limited in browsers and screen readers. Things are set to improve with SVG2, but ARIA can be used now to improve the accessibility of simple SVG.

The issues of this pattern are now widely recognized, but what’s the real solution?

There are too few things not to like about SVG, and I don’t mean the things that browsers cause by incomplete or lack of certain features or buggy implementations. via Pocket

JavaScript code to process elements on page load on a Drupal 7 site uses behaviours.

"- А у вас есть некий набор стилистических паттернов? Например: предложить клиенту 20 вариантов обоев для сайта.

• Нет. Мы стараемся давать один вариант дизайна."

But lately (several months) I’ve been thinking can we use SVG icons in Social Menu instead of icon fonts. Leland Fiegel picked up my question in Twitter and rolled his own idea. It’s not bad solution but what if we could do this without Javascript.

Do you add a descriptive title attribute to your links? Did you know that you might be making your site even less accessible? Everything I thought I knew about the title attribute was proved wrong when I started using a screenreader.

...And a crossbrowser sticky footer solution

Icons! We see them all over the web, and they're essential to most pattern libraries and web design systems. I recently needed to implement such a system. It had to be non-prescriptive, scalable, and dynamically editable via CSS. The icons were to be used by multiple teams in many different applications, built with various frameworks and techniques. They needed to have the ability to be restyled, get cached, and be updated quickly and easily as more icons are added. Basically, the icon system needed to be really, really flexible. Challenge accepted.

Ideally, we should all be developing our code in our own little space on our own little local server. This allows us to easily make changes without messing up production code or stepping over other's work. This is usually cost prohibitive so we're "forced" to use virtual machines to make this a reality.

The problem we face is that each developer needs to have a virtual machine that is setup exactly (or nearly exactly) like our production server. This requires a long list of configuration changes that need to be made on every machine. For example, install the apache package, update this configuration file, setup MySQL so you can access the databases remotely. Then we run into more problems when additional changes are needed because the developer has to take time out of their schedule to make them on each machine. There are also passwords that have to be remembered and /etc/host changes that need to be made. You'll be in even worse shape if the deployment consists of multiple VMs.

Icons are everywhere. These “little miracle workers” (as John Hicks described them) help us reinforce meaning in the interfaces we design and build. Their popularity in web design has never been greater; the conciseness and versatility of pictograms in particular make them a lovely fit for displays large and small.

But icons on the web have had their fair share of challenges. They were time-consuming to prepare for every intended display size and color. When high-resolution displays hit the market, icons looked particularly low-res and blocky compared to the text they often accompanied.

So it’s really no wonder that icon fonts became such a hit. Icons displayed via @font-face were resolution-independent and customizable in all the ways we expected text to be. Sure, delivering icons as a typeface was definitely a hack, but it was also useful, versatile, and maybe even a little fun.

But now we need to stop. It’s time to let icon fonts pass on to Hack Heaven, where they can frolic with table-based layouts, Bullet-Proof Rounded Corners and Scalable Inman Flash Replacements. Here’s why…

Interestingly I found that there are two actions taken by the browser: firstly on the percentage itself - for example - Internet Explorer 7-11 will truncate any percentage to 2 decimal places, more modern browsers will round to a large number of decimal places.

Slideshows, sliders, carousels: whatever you call them, in terms of web design they are just evil. Do a quick Google search and you will see that most frontend developers and UX/UI designers can agree on this point and have been talking about it for years. But why do we still constantly see them? Part of the issue is that slideshows, especially in the hero region, are so ubiquitous that many clients see them as necessary and keep asking for them. They have essentially become a “home page standard.”

The @extend directive in Sass can produce undesirable side effects. David Khourshid shows how to use @extend effectively to produce clean & organized CSS.

When we work at scale, we often find that we spend a large amount of our time reading, maintaining, and refactoring existing code, rather than writing and adding new features. This is the reason we focus so much on things like architectures, naming conventions, methodologies, preprocessors, scalability, etc.: because writing CSS is easy; looking after it is not.

Luckily for us, solutions exist to the problem of creating fast, responsive, fully customizable grids: Susy is a Sass-based grid framework. It’s very lightweight and enables you to create entirely custom grids in CSS without touching your markup.

@extend is now widely considered an anti-pattern, so its usage is thankfully fading out, but we’re not quite there yet.

Care must be taken when implementing icon fonts to ensure a great experience for all users. What happens when your font doesn’t load? What happens when @font-face isn’t supported in the browser? We’ll show you how to implement bulletproof font icons.