Accessibility, also known as “a11y”, refers to how well a website functions for people with disabilities. Common examples of disabilities in this space include visual conditions like color-blindness, vestibular conditions like animation nausea, and motor disabilities such as cerebral palsy, which happens to be the focus of this article.

The Feature

I am tasked with creating a “jump menu” for navigating tag archives.  Something like this:

Animated GIF - Find & Share on GIPHY

There is no submit button.  By merely selecting a menu item, the page navigates to that particular tag archive.  The premise of this UI is that, by not having to click a “submit” button, we save the user time and decision-making, hopefully improving the experience.

The Problem

This all works well enough, assuming you’re using a mouse.  But what happens if you’re using a keyboard?  Continue Reading How We do Accessibility: A Case Study

JavaScript wrangling has been among the most controversial topics in front-end development for a long time now. It’s right up there with tabs vs spaces and french press vs pour over. Here’s how we do at LexBlog in all current and foreseeable projects.

The Global Object

We kick off a plugin/theme JS file with a global that is namespaced for that project, containing handy functions used throughout.  Example:

Continue Reading How We Boilerplate our JavaScript

I was looking forward to writing about an intriguing bug in the new FireFox Quantum browser. I was looking forward to depicting the obscure CSS syntax that it bungles, and I was looking forward to explaining just what I plan to do about that. Given the rash of workplace abuses in the news lately, I’m not going to write about technology this week. Instead I’m going to write about the best advice I’ve ever heard:

Be absolutely professional in everything you do.Larry Ullman

Larry Ullman is the biggest influence on my career as a programmer. I’ve devoured all of his books many times. It is no exaggeration to say that the reason I have a family is because of the words this man has written in many, many books. And from all of his sage wisdom, that right there is the pearl. This advice was originally in reference to something quaint, like code or clients or invoices. It still works for that stuff.

Honestly, I struggle with this advice every single day. I often re-read myself in tickets or emails and wish that I had found a way to be more patient, more thorough, more researched. But what I can’t fathom is a workplace where this struggle includes the desire to harm a coworker physically or mentally.

It’s been a while Larry, but there are many of us out here who still read your books and still take your advice. And many more who should.

I often work with exactly one plugin active, other than the plugin I’m working on and its dependencies. That plugin is Query Monitor. QM adds a button to the admin bar that turns red when I make mistake, and reveals a treasure land of begun info when I click on it.

We go live to me making a mistake.

QM is completely free and has inspired a vibrant community of side-plugins, that hook in and provide even deeper debug info about specific topics. It’s updated frequently and is active on over 30,000 websites. The author, John Blackbourne, actively engages feedback on Twitter. We use it a lot here at LexBlog. It’s not a hard policy per se, but I strongly recommend to my teammates that they never work without it.

John Steinbeck once said to write for an audience of one:

In writing, your audience is one single reader. I have found that sometimes it helps to pick out one person—a real person you know, or an imagined person and write to that one.

Similarly, I think many of the best plugins come about when, as developers, we code for our own needs — our own audience of one. I’ve also heard this called “dogfooding” and I like it.

Query Monitor has taught me about my own mistakes and failings thousands of times. On this day of giving thanks, I give thanks to you, Query Monitor!

I try not to get overly technical in this space, but when I get a chance to implement one of my very favorite programming techniques, I have a hard time keeping it to myself.  I want to tell you about recursion.  Per wikipedia:

A common method of simplification is to divide a problem into subproblems of the same type […] where problems are solved by solving smaller and smaller instances.

Here’s the example.  Earlier this week I was dealing with a problem where I needed to turn the english words “true” and “false” into the boolean values true and false.  This would be easy enough to do if it were simply one instance of the words:

Continue Reading Recursion

There’s nothing wrong with making mistakes, in fact I highly recommend it. However, if I make a mistake and I have no plan for preventing it from happening again, that feels pretty lame. One mistake I have made before, is forgetting if I am on a live installation or a staging installation. When I say live and staging, I’m referring to WP-Engine’s excellent system.

I made this mistake recently while working on a site for a friend, and it was embarrassing. I decided that a good way to prevent it, would be to add an obvious visual cue to alert the user when they are on a staging site. I found some time this week to write a small plugin that does exactly that:

See the yellow “hazard” tape at the bottom? If you click it, it fades out so it’s not in the way. It’s my way of saying, “Hey! You are on staging.”

Instead of hosting this plugin in our normal repository, I decided to host it on WordPress.org. That way I can use it on my friend’s site, in addition to our LexBlog sites. And so can you:

LXB Staging Reminder

Recently our reporting software, NewRelic, alerted us that some of our code was running slower than usual:

The graph depicts a dramatic decrease in performance on October 11.

I was able to trace it back to a recent update where, in order to make our code more flexible, I began to register and accept default values for various database settings:

New code to allow us to easily register default values for settings that have not yet been set.

Surprisingly, this added up to a palpable slowdown.  We have tons of options in our Apple Fritter theme, hundreds actually, so running this routine potentially hundreds of times per page load was turning out to be a drag.  Here’s what we’re doing now instead:

(Click the image to enlarge) If the value has not yet been set, we’ll actually set it to the default, instead of merely using the default.

See the difference?  If the value has not yet been set, and a default is available, I’ll use the default to set the value.  Therefore, in the future, we never have to go through the routine of locating the default value.

Front-end database writes like that are generally a bad practice.  To write is more expensive than to read.  But in this case, the database write is merely a gambit:

A gambit (from ancient Italian gambetto, meaning “to trip”) is a chess opening in which a player, more often White, sacrifices material, usually a pawn, with the hope of achieving a resulting advantageous position.

I’m paying a one-time penalty to never have to read the default value again.  You can see the subsequent reporting in NewRelic:

The original decrease in performance, followed by an even worse one, followed by restored performance.

Notice the spike in load time, followed by the dip.  The spike occurred on the first few page loads after I allowed for front-end database writes to populate a value.  After that, things actually accelerated to faster than they were before!