Category: Design & Dev

accessibility

Form Follows Function: How to Properly Label Online Form…

When was the last time you enjoyed filling out a form? No, seriously, like really enjoyed it? I mean kicked in your roommate’s bedroom door to show them a video of a gaze of chunky adorable raccoons tearing at a grown man holding a storage container full of hotdogs kinda fun. Never?

Not surprising. Because, the role of a form isn’t to be fun. A form is a tool that collects data from a user, usually in exchange for services or additional information. A form needs to be efficient, elegant, and accessible.

Forms that meet the criteria I just laid out are more likely to see submissions (conversions). That’s because these forms will clearly request information, which limits confusion, which in turn means your users will more often than not fill in the form correctly and submit it on their first try.

Forms are a big topic where accessibility, user experience, and CRO are concerned. And while there are varying opinions on how to approach forms from each perspective, there is one tactic that is a simple starting point to an elegant, accessible form that all disciplines can agree on: proper form field labeling. When done right, label elements expand the interact-able range of your fields. When a user clicks or focuses on a label, that part of your form will gain focus. No wasted space; the labels actively assist in form completion.

However, when done incorrectly, form label elements can actually detract from the user experience, impact accessibility, and ultimately lead to decreased conversions.

Common Form Label Problems

In my experience the most common issue I find when auditing forms for accessibility is poor labeling. Labels are often hidden and “replaced” with some other aspect of a field. Here are a few examples of those replacements. Let us see how many you are guilty of…

  • Hiding or excluding a label and “replacing” it with the placeholder attribute on an input field.
  • Adding a valueless option as the first choice in a select field as a way to describe the field’s purpose instead of displaying a label. Example “What country do you live in?” or “Current level of existential dread?”
    In this example, the selection instructions "how many kittens do you need" is within the text field, which is incorrect. Instead, the description of what this question is looking for should live permanently above the input field.
  • Not labeling a group of checkboxes/radio buttons, but attempting to convey the overall meaning of the group through the individual choices.
    In this example, the user should select between two options, "a taco is my preferred sandwich" and "a hot dog is my preferred sandwich." However, the section has no label and the radio button text attempts to provide context, which is incorrect. Instead, the group should be labelled "what type of sandwich do you prefer?" with the options being simply "taco" or "hot dog."

These solutions usually meet aesthetic wants or satisfy internal requests, but none are correct. There is no substitute for a field label. They are a requirement and need to be kept visible and consistent. Should you find yourself in a disagreement about displaying labels vs. not displaying them, the person on the display side of the argument is correct.

Anatomy of the Label Element

To start off, I will clarify what the label element is and how it’s used in practice.

A label is a textual element in HTML that links to a field to supply more context. The most general usage of a label serves as the title of a field, such as “first name” or “zip code.” Label usage also extends to error messages for specific fields as a way to link errors to a field so that assistive technology can easily access the error message language.

A label element is opened and closed with the <label> and </label> tag. General attributes like “ID” and “class” can be applied but labels specifically support the”‘for” attribute, which is used to link the label to a specific field. The value of the “for” attribute is the ID of the field the label is tied to. Here is all the markup it takes to do it right:

<label for=“firstNameField”>First Name</label>

<input id="firstNameField" type="text"/>

Correctly Implementing Labels in Your Forms

For some, merely discussing the issues in the previous section could be enough to correct them. For everyone still here, this section is where I will dive into how to properly label an online form.

Keep Labels Visible and Consistently Placed

Easy. Don’t hide labels and keep them in the same place. It really is that simple. The label can go above, below, or to the left side of the field; there are plenty of options to design around.

Do Not Use the Placeholder Attribute as a Label

As I mentioned in the common problems section, the placeholder attribute of a field is not a replacement for a label. Placeholders disappear when a field is changed and generally have lower visibility.

Avoid Floating Labels

I also do not recommend using floating labels. This is a design pattern where the label of the field is present, but lays over the input until the user clicks or focuses into it. The label then moves out of the way—or worse—fades out. Often, this little touch of flair causes the label’s text to shrink, and the user may not properly track the animation or change in visual state. This introduces possible points of friction and really isn’t worth the perceived oomph.

Avoid Generic Labeling

Before I go into detail about repeated labels I would like to touch on generic ones. The label attached to a field should clearly communicate the information needed to successfully complete the form. A field that requires a user’s full name is a good example of how a strong descriptive label can convey the request.

A generic label in a form will not get flagged as a WCAG failure, it is not a requirement but… I consider generic labels to be an accessibility concern because unclear communication can make access to content and services difficult. Lack of clarity creates friction, and friction repels users.

To provide an example of a generic label let’s examine a field that expects a user to supply their full name that is only labeled “name.” Name what? Name is generic and leaves a lot of room for interpretation. More context should be supplied to narrow down possibilities and instruct the user to complete the field successfully.

A better label would be “Full Name.” This can be taken further considering the purpose of the information; “Legal Name,” “Your Name,“ “First and Last Name,” or “Preferred Name” are better, more descriptive examples of a label that requests a name from a user.

I have an anecdote about generic field labeling to share. It revolves around a form that collected information for a home moving quote. An important field on the form collected the expected date of the move and was labeled, simply, “Move Date.” This crucial field was causing users to bounce from the form before submitting it.

The solution to the problem you ask? Changing the label to “Estimated Moving Date.” One small change to the label increased the completions of the form. The added context of the word “estimated” conveyed to the user that they can ask for a quote without being 100% certain of their moving date.

Avoid Repeating Labels

Something worth noting is that because a label references the ID of a field, one field could have multiple labels that reference it but a single label can only reference one field. In most cases that shouldn’t be a problem, but this is the internet which means one size doesn’t fit all.

For example, imagine a form that asks the user to list four favorite foods. It would be redundant to have four fields that each have a generic label of “favorite food,” or even more specific labels of “favorite food 1,” “favorite food 2,” and so on. If your form allowed the user to add infinite favorite foods, this would get ridiculous.

Should you find yourself in a place where you need one label to apply to multiple fields, there is a way to do that using the “aria-labelledby” attribute.

Using Aria-labelledby for Multiple Fields With the Same Label

If you are unfamiliar with ARIA I want to quickly touch on two things. First, it stands for Accessible Rich Internet Applications and is an additional set of markup in HTML specifically for assistive technology. Second, is a warning that ARIA has to be used correctly or it can really mess up the experience for an assistive technology user. If you don’t need to use it, then it’s best you don’t.

But now back to my example. You gotta have those “favorite food” labels! aria-labelledby is placed on the input element, and references the ID of the label that applies to the field. aria-labelledby can also tie multiple labels to a single field by putting a space between each ID.

Here is an example of aria-labelledby being applied to four text fields that all use the same label:

<label id="favFoodLabel">Favorite Foods</label>

<input type="text" aria-labelledby="favFoodLabel"/>

<input type="text" aria-labelledby="favFoodLabel"/>

<input type="text" aria-labelledby="favFoodLabel"/>

<input type="text" aria-labelledby="favFoodLabel"/>

That’s It!

Ensuring labels are present and properly linked to fields, keeping them visible, and making sure they are clear and descriptive are some easy steps to creating good forms that allow the most amount of people to interact with them. And while I understand that Minimalism is a tempting (and popular) design philosophy, the forms you put out in the world can be aesthetically pleasing, but that goal should be secondary to functionality. You, the person reading this, likely fill out forms all the time. Search your experiences and think of how many times you needed a form to be useful and respect your time rather than fun to look at.

We also put a really nice form on this page that properly instructs you to supply your email address in return for blog updates. You should try it, for educational purposes… of course.

The post Form Follows Function: How to Properly Label Online Form Fields appeared first on Portent.

Design & Dev

A Web Dev’s Checklist for Maintaining Page Speed

Updated on December 1, 2020 to include details on running a page speed audit and new page speed tips, including Core Web Vitals and eliminating render-blocking resources.

It’s obvious to say that all websites need upkeep, but oftentimes they are designed and then left as “good enough.” Collecting dust, attracting hackers, slipping in the rankings. We’ve already gone into painstaking detail about why page speed matters and various levels of guidance for site speed optimization overhaul from novice to advanced. This article assumes you’ve implemented most of those major improvements, at least somewhat recently. If you haven’t, then definitely do start here.

In this post, we’ll look at how to run a quick and dirty page speed audit and target the most critical culprits affecting page speed, as well as basic fixes to help keep the base layer of the marketing stack (infrastructure, page/site speed) healthy.

Infrastructure drives digital marketing. It’s the base of the Marketing Stack.

Running a Page Speed Audit

There are two main tools that I recommend using for page speed audits: Google PageSpeed Insights and WebPageTest.org. You can quickly get an overview of a site’s performance by running and analyzing the results from these programs.

PageSpeed Insights

Google’s algorithms have always been at the center of site performance. They continue to push the bar higher, and with the advent of Google’s Core Web Vitals, the results of their tools will be center stage with clients. We must appease the Google gods, which we have been doing for well over a decade at this point. PageSpeed Insights (PSI) utilizes the Google web tool, Lighthouse, to collect and analyze performance data. PageSpeed Insights puts it all together and provides recommendations for improvements. PSI focuses on the web application alone and does not specifically analyze other environment performance issues.

""

WebPageTest.org

WebPageTest is a solid tool that gives a little more of a top-level view of a site’s performance. It focuses on seven categories: security (new), time to first byte (TTFB), keep-alive, compress transfer, image optimization, static content caching, and use of content delivery network(s) (CDN). It does not dissect a website nearly as much as Lighthouse, but its focus on what I consider Tier I best practices helps establish a great starting point for improvement.

""

Tips for Addressing the Page Speed Audit Results

The topics and subsequent tips below are not an exhaustive list of the page speed audit results, but they are the ones we feel need to be addressed on an ongoing basis to have the most impact on your site. For an in-depth look, check out our Ultimate Guide to Page Speed.

Core Web Vitals

Addressing poor Core Web Vitals (CWV) scores should be a focal point of ongoing maintenance for improving site speed. I’m not going to go into detail about what Core Web Vitals are in this article because we’ve already written about it here. But CWV will become a ranking factor on Google, so it has SEO implications aside from the more obvious user experience implications.

Maintenance Tip: Test, analyze, and address Core Web Vitals scores on a quarterly basis.

Render-Blocking Resources

This page speed checklist audit item is the unicorn. It’s probably the most critical and challenging performance item for a web app. It’s critical because render-blocking resources drastically delay the loading of a web page until said resource is downloaded and processed—it directly impacts a fast user experience. It’s challenging because, for most web applications, it requires a fairly complex system to be implemented.

That complex system involves critical CSS to be generated for every page and all subsequent styles loaded asynchronously. Additionally, it is ideal that all JavaScript is either loaded asynchronously, deferred, or at the bottom of the page’s source code. While that may seem like a straightforward solution, there is a lot packed into those two sentences.

A majority of web applications are built on content management systems (CMS), which come with a whole library of scripts. Plugins or modules are often used to extend functionality, and those also come with their own scripts. All of these have to be considered when implementing a solution, which is why it is much easier to execute on new site builds that properly plan for said solution as a feature.

I recommend researching, planning, and working on implementing a system that eliminates as many render-blocking resources as possible for your web application. It will not be a quick or easy project, but it is necessary for improving site speed scores, including directly affecting Core Web Vital scores. Generally speaking, expect a solution to take anywhere from 20-50+ hours to implement, depending on the complexity of your web app.

Once a solution is in place, keep an eye on the application as additional functionality is added.

Maintenance Tip: Inspect for any new render-blocking resources regularly and try to eliminate as many as possible.
Maintenance Tip: Re-generate critical CSS when changes have been made to above-the-fold styles.

Image Compression

Over time, lots of content gets added, edited, and generally messed with on your site. Content producers upload images, page templates get a facelift, and so on. In the hustle to keep our content fresh, compelling, and published on-time, marketers can easily forget to follow the image compression procedures that we carefully laid out the last time we did a site speed push.

Whatever the reason for the average image size creeping up, if images are not optimized before they go live, or auto-optimized on upload, it won’t take long for your newest content to under-perform.

Maintenance Tip: Test a handful of your main pages quarterly like the homepage, blog hub, services page, products hub, etc., on webpagetest.org. Analyze the results and make sure you address image compression issues.

Identify where and how over-sized images are popping up most frequently, and proactively address them with the folks who can improve their process. Teach your content team how they can optimize imagery for your site. Better still, if you’re on WordPress, implement a plugin that will auto-optimize your imagery on upload. Two of our favorites are EWWW Image Optimizer and Smush.

HTACCESS Rules Overwritten

This may sound like a strange culprit, but it definitely happens. A CMS and/or plugin modifies the local Apache config file (.htaccess), and in the process, wipes out a bunch of browser caching or compression directives.

Maintenance Tip: Be sure that you’re still defining max-age (or far off) expiration times for your static files like images, CSS, JavaScript, fonts, etc.

JavaScript and CSS Bloat

Have you added any plugins to extend functionality lately? More often than not, plugins inject their own javascript and CSS on every page, even if they’re only truly being utilized on a few.

Maintenance Tip: Customize your theme (or app) to remove these unnecessary resources where they are not needed. This can be tedious, but taking the time to limit all plugins to only the uses and pages where they’re needed will add up to improve your performance metrics and enhance your customers’ experience on your site.

3rd Party Scripts

Marketers love their tools. They provide great insights into all kinds of metrics to help make informed decisions, from page views and click-throughs to heat maps and scroll tracking. But sometimes they love their tools too much—and subsequently, have their dev team install a bunch of 3rd party scripts into the code.

With the advent of Google Tag Manager, marketers can even insert some of these scripts themselves, which opens its own can of worms that we won’t get into. We’re big fans of GTM in general for the agility and visibility it brings to marketing teams, but as a developer that knows the value of site speed, you still need to understand all the code that’s going into your site.

Maintenance Tip: Coordinate with your analytics and/or marketing teams who utilize these tools and analyze them carefully. Be picky about what you are running on your site. Purge scripts that are no longer needed (or no longer work).

Updates to Your CMS, Plugins, Extensions, and Modules

Regardless of your CMS, you should be keeping up with core updates for security patching and enhanced functionality. Sometimes, the updates are improvements to code efficiency. Plus, you don’t want to fall so far behind that when you finally address updates, they are of the large, complicated, headache variety. Iterative updates for the win!

The same goes for any plugins or extensions.

Maintenance Tip: Be vigilant about CMS updates. Keep ’em small and painless. If a faster site wasn’t enough incentive, you don’t want to be unknowingly advertising for hackers, right?

To Recap

This should be a fairly simple, manageable list to get your site’s performance back on the right track — and, most importantly, convert more leads. I would suggest reviewing once a month, and if you haven’t made any investment in site speed before this, definitely check out Portent’s Massive Guide To Page Speed as a starting place.

Pssst: Portent does page speed optimization. Give us a call.

The post A Web Dev’s Checklist for Maintaining Page Speed appeared first on Portent.

Translate »