Snippets

HTML tests for various uses, including HTML5accessibility.com and JAWS tests

For perhaps the first time since the original Macintosh, we can get excited about using system UI fonts. They’re an interesting, fresh alternative to web typography — and one that doesn’t require a web-font delivery service or font files stored on your server. How do we use system UI fonts on a website, and what are the caveats? System UI fonts being amazing kind of snuck up on us. Google has been toiling away at Roboto with great success (including regular updates), Apple made a splash with San Francisco, and Mozilla asked renowned type designer Erik Spiekermann to create Fira Sans.

The first grouping is CSS properties that map to the system’s UI font. That covers a lot of ground, and there is no chance that these fonts will be mistaken for something else:

• -apple-system targets San Francisco in Safari on Mac OS X and iOS, and it targets Neue Helvetica and Lucida Grande on older versions of Mac OS X. It properly selects between San Francisco Text and San Francisco Display depending on the text’s size.
• BlinkMacSystemFont is the equivalent for Chrome on Mac OS X.

The second grouping is for known system UI fonts:

• Segoe UI targets Windows and Windows Phone.
• Roboto targets Android and newer Chrome OS’. It is deliberately listed after Segoe UI so that if you’re an Android developer on Windows and have Roboto installed, Segoe UI will be used instead.
• Oxygen targets KDE, Ubuntu targets… well, you can guess, and Cantarell targets GNOME. This is beginning to feel futile because some Linux distributions have many of these fonts.
• Fira Sans targets Firefox OS.
• Droid Sans targets older versions of Android.
• Note that we don’t specify San Francisco by name. On both iOS and Mac OS X, San Francisco isn’t obviously accessible, but rather exists as a “hidden” font.
• We also don’t specify San Francisco using .SFNSText-Regular, the internal PostScript name for San Francisco on Mac OS X. It only works in Chrome and is less versatile than BlinkMacSystemFont.

The third grouping is our fallback fonts:

• Helvetica Neue targets pre-El Capitan versions of Mac OS X. It is listed close to the end because it’s a popular font on other non-El Capitan computers.
• sans-serif is the default sans-serif fallback font.

Ever get annoyed with carousels and similar widgets that have that sort sticky pause when you swipe and release? Well, Flickity totally fixes that by handling momentum in an intuitive way.

What do you do if you want to use a Drupal.org sandbox project with Composer? You can’t just add it in your "require" section, as it won’t be available as a package name. Turns out you just have to define the repository in your composer.json like so:

Bet you didn’t know that both GitHub and GitLab can provide you with a patch file by appending “.patch” to the end of the commit URL? I sure didn’t. For example, this commit:

https://gitlab.com/Ambient.Impact/drupal-modules/commit/6b4b2e808cb842de83c97a722b804e1ca88a2e7f

becomes:

https://gitlab.com/Ambient.Impact/drupal-modules/commit/6b4b2e808cb842de83c97a722b804e1ca88a2e7f.patch

This is super useful when you need to use a patch for a Composer package, etc.

Today is Global Accessibility Awareness Day - a great day to be talking about accessibility.

[…]

Accessibility is for everyone, it’s not an edge case.

Accessibility is cumulative not binary, the more you do for accessibility the more accessible your site is.

Use semantic HTML, browsers have a lot of accessibility built in.

Make things keyboard operable by using the keyboard from time to time when you’re developing.

Finally, you don’t have to ask permission to make things accessible.

The easiest way is to ensure that the config has a dependency on your module.

dependencies:
  enforced:
    module:
      - yourmodule

Then Drupal will automatically remove that configuration and also warn in the UI that it will be removed.