HTML5 brought with it new values of the type attribute that enabled us to be much more specific about the types of data we needed to capture through the field, with the promise being that the browser would then provide the interface and validation required to coerce the user into completing the field accurately.
Having new items in a spec is one thing, but it doesn’t really mean too much unless the browsers our audience are using support those features. These new values of the type attribute had the big advantage of falling back to type="text" if the browser had no support, but this may have also come at the cost of removing the browsers makers’ imperative when it came to implementing those new types in their products.
It’s the start of 2019, and HTML5 has been the current version of HTML now for more than four years. Which of those new types have been implemented, which can we use, and are there any we should be avoiding?
The type="search" input is intended to be used for search fields. Functionally, these are very the same as basic text fields, but having a dedicated type enables the browser to apply different styling. This is particularly useful if the user’s operating system has a set style for search fields, as this enables the browser to style the search fields on web pages to match.
The specification states that the difference between search and text is purely stylistic, so it may be best to avoid this if you intend to restyle the field with CSS anyway. There appears to be no semantic advantage to its use.
Use type="search" if you intend to leave the styling of the search field up to the browser.
2. Telephone Number Fields
The type="tel" input is used for entering telephone numbers. These are like the unique usernames used by Whatsapp. If you’re unsure, ask your grandparents.
On desktop browsers, the use of telephone fields seems to have little impact. On devices with virtual keyboards, however, they can be really useful. For example, on iOS, focusing input on a telephone field brings up a numeric keypad ready for keying in a number. In addition, the device’s autocomplete mechanisms kick in and suggest phone numbers that can be autofilled with a single tap.
Use type="tel" for any phone number fields. It’s very useful where implemented, and comes at no cost when it’s not.
3. URL Fields
The type="url" field can be used for capturing URLs. You might use this when asking a user to input their website address for a business directory, for example. The curious thing about the URL field is that it takes only full, absolute URLs. There’s no option to be able to capture just a domain name, or just a path, for example. This does restrict its usefulness in some respects, as I imagine CMS and web app developers would have found lots of uses for a field that accepts and validates relative paths.
While this would be a valid absolute URL:
Both of these would not pass the field’s validation:
It feels like a missed opportunity that different parts of a URL cannot be specified, but that’s what we have. Browser support is across the board pretty great, with virtual keyboard devices offering some customization for URL entry. iOS customizes its keyboard with ., / and an autocomplete button for common TLDs such as .com and for my locale, .co.uk. This is a good example of the browser being able to offer more intelligent choices than we can as web developers.
Use type="tel" whenever you need to collect a full, absolute URL. Browser support is great, but remember that it’s no good for individual URL components.
4. Email Fields
Possibly one of the most commonly used of the newer options is type="email" for email addresses. Much like we’ve seen with telephone numbers and URLs, devices with virtual keyboards customize the keys (to include things like @ buttons) and enable autofill from their contacts database.
Desktop browsers make use of this too, with Safari on macOS also enabling autofill for email fields, based on data in the system Contacts app.
Email addresses often seem like they follow a very simple format, but the variations actually make them quite complex. A naive attempt to validate email addresses can result in a perfectly good address being marked as invalid, so it’s great to be able to lean on the browser’s more sophisticated and well-tested validation methods to check the format.
Usefully, the multiple attribute can be added to email fields to collect a list of email addresses. In this case, each email address in the list is individually validated.
Use type="email" for email address fields whenever possible.
5. Number Fields
The type="number" field is designed for numerical values, and has some very useful attributes along with it in the shape of min, max and step. A valid value for a number field must be a floating point number between any minimum and maximum value specified by the min and max attributes.
If step is set, then a valid value is divisible by the step value.
<input type="number" min="10" max="30" step="5">
Valid input for the above field would be 10, 15, 20, 25 and 30, with any other value being rejected.
Browser support is broad, again with virtual keyboards often defaulting to a numeric input mode for keying in values.
Some desktop browsers (including Chrome, Firefox and Safari, but not Edge) add toggle buttons for nudging the values up and down by the value of step, or if no step is specified, the default step appears to be 1 in each implementation.
Use type="number" for any floating point numbers, as it’s widely supported and can help prevent accidental input.
6. Range Fields
Less obvious in use that some of the other types, type="range" can be thought of as being an alternative for type="number" where the user doesn’t care about the exact value.
Range fields take, and will often use, the same min, max and step attributes as number fields, and browsers almost universally display this as a graphical slider. The user doesn’t necessarily get to see the exact value they’re setting.
Range fields might be useful for those sorts of questions on forms like “How likely are you to recommend this to a friend?” with “Likely” at one end and “Unlikely” at the other. The user could slide the slider to wherever they think represents their opinion, and under the hood that gets submitted as a numerical value that you can store and process.
Browser support is good, although the appearance varies between implementations.
Can I Use input-range? Data on support for the input-range feature across the major browsers from caniuse.com.
The uses for type="range" might be a bit niche, but support is good and the slider provides a user-friendly input method where appropriate.
7. Color Fields
The type="color" field is design for capturing RGB colors in hexadecimal notation, such as #aabbcc. The HTML specification calls this a “color well control”, with the intention that the browser should provide a user-friendly color picker of some sort.
Some browsers do provide this, notably Chrome and Firefox both providing access to the system color picker through a small color swatch.
Neither IE nor Safari provide any support here, leaving the user to figure out that they’re supposed to enter a 7-digit hex number all by themselves.
Color fields might find use in theming for personalization and in CMS use, but unless the users are sufficiently technical to deal with hex color codes, it may be better not to rely on the browser providing a nice UI for these.
Can I Use input-color? Data on support for the input-color feature across the major browsers from caniuse.com.
Unless you know your users will be happy to fall back to entering hexadecimal color codes, it’s best not to rely on browsers supporting type="color".
8. Date Fields
HTML5 introduced a number of different type values for creating inputs for dates and times. These included date, time, datetime-local, month and week.
At first glance, these appear to be heaven-sent, as collecting dates in a form is a difficult experience for both developer and user, and they’re needed pretty frequently.
The promise here is that the new field types enable the browser to provide a standardized, accessible and consistent user interface to capture dates and times from the user with ease. This is really important, as date and time formats vary world-over based on both language and locale, and so a friendly browser interface that translates an easy-to-use date selection into an unambiguous technical date format really does sound like the ideal solution.
As such, valid input for type="date" field is an unambiguous year-month-day value such as 2019-01-16. Developers like these, as they map pretty much to the ISO 8601 date format, which is used in most technical contexts. Unfortunately, few regular human beings use this date format and aren’t likely to reach for it when asked to provide a date in a single empty text field.
And, of course, a single empty text field is what the user is presented with if their browser does not provide a user interface for picking dates. In those cases, it then becomes very difficult for a user to enter a valid date value unless they happen to be familiar with the format required or the input is annotated with clear instructions.
Many browsers do provide a good user interface for picking dates, however. Firefox has a really excellent date picker, and Chrome and Edge also have pretty good interfaces. However, there’s no support in poor old IE and none in Safari, which could be an issue.
While convenient where it works, the failure mode of type="date" and its associated date and time types is very poor. This makes it a risky choice that could leave users struggling to meet validation criteria.
A lot has changed in the browser landscape in the four years since the HTML5 specification became a recommendation. Support for the newer types of input is fairly strong — particularly in mobile devices with virtual keyboards such as tablets and phones. In most cases, these inputs are safe to use and provide some extra utility to the user.
Why is Google the search behemoth it is today? Part of the reason is because of how it’s transformed our ability to search for answers.
Think about something as simple as looking up the definition of a word. 20 years ago, you would’ve had to pull your dictionary off the shelf to find an answer to your query. Now, you open your phone or turn on your computer, type or speak the word, and get an answer in no time at all and with little effort on your part.
This form of digital shortcutting doesn’t just exist on search engines like Google. Mobile apps now have self-contained search functions as well.
Is a search bar even necessary in a mobile app interface or is it overkill? Let’s take a look at why the search bar element is important for the mobile app experience. Then, we’ll look at a number of ways to design search based on the context of the query and the function of the app.
Using The Web With A Screen Reader
Did you know that VoiceOver makes up 11.7% of desktop screen reader users and rises to 69% of screen reader users on mobile? It’s important to know what sort of first-hand difficulties visually impaired users face and what web developers can do to help. Read article →
Mobile App Search Is Non-Negotiable
The search bar has been a standard part of websites for years, but statistics show that it isn’t always viewed as a necessity by users. This data from Neil Patel and Kissmetrics focuses on the perception and usage of the search bar on e-commerce websites:
As you can see, 60% of surveyed users prefer using navigation instead of search while 47% opt for filterable “search” over regular search functionality.
On a desktop website, this makes sense. When a menu is well-designed and well-labeled — no matter how extensive it may be — it’s quite easy to use. Add to that advanced filtering options, and I can see why website visitors would prefer that to search.
But mobile app users are a different breed. They go to mobile apps for different reasons than they do websites. In sum, they want a faster, concentrated, and more convenient experience. However, since smartphone screens have limited space, it’s not really feasible to include an expansive menu or set of filters to aid in the navigation of an app.
This is why mobile apps need a search bar.
You’re going to find a lot of use for search in mobile apps:
Content-driven apps like newspapers, publishing platforms, and blogs;
e-Commerce shops with large inventories and categorization of those inventories;
Productivity apps that contain documents, calendars, and other searchable records;
Listing sites that connect users to the right hotel, restaurant, itinerary, item for sale, apartment for rent, and so on;
Dating and networking apps that connect users with vast quantities of “matches”.
There are plenty more reasons why you’d need to use a search bar on your mobile app, but I’m going to let the examples below speak for themselves.
Ways To Design Search For Your Mobile App
I’m going to break down this next section into two categories:
1. Full-width bar at the top of the app. This is for apps that are driven by search. Most of the time, users open the app with the express purpose of conducting a search.
Facebook is a good example. Although Facebook users most likely do engage with the news feed in the app, I have a sneaking suspicion that Facebook’s data indicates that the search function is more commonly engaged with — at least in terms of first steps. Hence, why it’s placed at the top of the app.
2. A tab in the bottom-aligned navigation bar. This is for apps that utilize search as an enhancement to the primary experience of using the app’s main features.
Let’s contrast Facebook against one of its sister properties: Instagram. Unlike Facebook, Instagram is a very simple social media app. Users follow other accounts and get glimpses into the content they share through full-screen story updates as well as from inside their endless-scroll news feed.
With that said, the search function does exist in the navigation bar so that users can look up other accounts to peruse through or follow.
As far as this basic breakdown goes, Sahay is right about how placement of search correlates with intention. But the designing of the search element goes beyond just where it’s placed on the app.
Shallow Or Deep?
There will be times when a mobile app would benefit from a search function deep within the app experience.
In this example, this search function exists outside of the standard product search on the main landing page. Results for this kind of search are also displayed in a unique way which is reflective of the purpose of the search:
There are other ways you use might need to use “deep” search functions on e-commerce apps.
Think about stores that have loads of comments attached to each product. If your users want to zero in on what other consumers had to say about a product (for example, if a camping tent is waterproof), the search function would help them quickly get to reviews containing specific keywords.
You’ll also see deep searches planted within travel and entertainment apps like Hotels.com:
You’re all probably familiar with the basic search function that goes with any travel-related app. You enter the details of your trip and it pulls up the most relevant results in a list or map format. That’s what this screenshot is of.
However, see where it says “Property Name” next to the magnifying glass? This is a search function within a search function. And the only things users can search for here are actual hotel property names.
Bar, Tab, Or Magnifying Glass?
This brings me to my next design point: how to know which design element to represent the search function with.
You’ve already seen clear reasons to use a full search bar over placing a tab in the navigation bar. But how about a miniaturized magnifying glass?
Here’s an example of how this is used in the YouTube mobile app:
The way I see it, the magnifying glass is the search design element you’d use when:
One of the primary reasons users come to the app is to do a search,
And it competes against another primary use case.
In this case, YouTube needs the mini-magnifying glass because it serves two types of users:
Users that come to the app to search for videos.
Users that come to the app to upload their own videos.
To conserve space, links to both exist within the header of the YouTube app. If you have competing priorities within your app, consider doing the same.
“Search” Or Give A Hint?
One other thing to think about when designing search for mobile apps is the text inside the search box. To decide this, you have to ask yourself:
“Will my users know what sort of stuff they can look up with this search function?”
In most cases they will, but it might be best to include hint text inside the search bar just to make sure you’re not adding unnecessary friction. Here’s what I mean by that:
The search bar tells me to “Try ‘Costa de Valencia’”. It’s not necessarily an explicit suggestion. It’s more helping me figure out how I can use this search bar to research places to stay on an upcoming trip.
For users that are new to Airbnb, this would be a helpful tip. They might come to the site thinking it’s like Hotels.com that enables users to look up things like flights and car rentals. Airbnb, instead, is all about providing lodging and experiences, so this search text is a good way to guide users in the right direction and keep them from receiving a “Sorry, there are no results that match your query” response.
2. Designing The Search Bar And Results In Context
Figuring out where to place the search element is one point to consider. Now, you have to think about how to present the results to your mobile app users:
This is the most basic of the search functions you can offer. Users type their query into the search bar. Relevant results appear below. In other words, you leave it up to your users to know what they’re searching for and to enter it correctly.
When a relevant query is entered, you can provide results in a number of ways.
For an app like Flipboard, results are displayed as trending hashtags:
It’s not the most common way you’d see search results displayed, but it makes sense in this particular context. What users are searching for are categories of content they want to see in their feed. These hashtagged categories allow users to choose high-level topics that are the most relevant to them.
ESPN has a more traditional basic search function:
As you can see, ESPN provides a list of results that contain the keyword. There’s nothing more to it than that though. As you’ll see in the following examples, you can program your app search to more closely guide users to the results they want to see.
According to the aforementioned Kissmetrics survey, advanced filtering is a popular search method among website users. If your mobile app has a lot of content or a vast inventory of products, consider adding filters to the end of your search function to improve the experience further. Your users are already familiar with the search technique. Plus, it’ll save you the trouble of having to add advancements to the search functionality itself.
In the search above, I originally looked for restaurants in my “Current Location”. Among the various filters displayed, I decided to add “Order Delivery” to my query. My search query then became:
Restaurants > Current Location > Delivery
This is really no different than using breadcrumbs on a website. In this case, you let users do the initial work by entering a search query. Then, you give them filters that allow them to narrow down their search further.
Again, this is another way to reduce the chances that users will encounter the “No results” response to their query. Because filters correlate to actual categories and segmentations that exist within the app, you can ensure they end up with valid search results every time.
e-Commerce websites are another good use case for filters. Here is how Wayfair does this:
Wayfair’s list of search results is fairly standard for an e-commerce marketplace. The number of items are displayed, followed by a grid of matching product images and summary details.
Here’s the thing though: Wayfair has a massive inventory. It’s the same with other online marketplaces like Amazon and Zappos. So, when you tell users that their search query produced 2,975 items, you need a way to mitigate some of the overwhelm that may come with that.
By placing the Sort and Filter buttons directly beside the search result total, you’re encouraging users to do a little more work on their search query to ensure they get the best and most relevant results.
Autocomplete is something your users are already familiar with. For apps that contain lots of content, utilizing this type of search functionality could be majorly helpful to your users.
For one, they already know how it works and so they won’t be surprised when related query suggestions appear before them. In addition, autocomplete offers a sort of personalization. As you gather more data on a user as well as the kinds of searches they conduct, autocomplete anticipates their needs and provides a shortcut to the desired content.
Pinterest is a social media app that people use to aggregate content they’re interested in and to seek out inspiration for pretty much anything they’re doing in life:
Take a look at the search results above. Can you tell what I’ve been thinking about lately? The first is how I’m going to decorate my new apartment. The second is my next tattoo. And despite only typing out the word “Small”, Pinterest immediately knew what’s been top-of-mind with me as of recent. That doesn’t necessarily mean I as a user came to the app with that specific intention today… but it’s nice to see that personalized touch as I engage with the search bar.
Another app I engage with a lot is the Apple Photos app:
In addition to using it to store all of my personal photos, I use this on a regular basis to take screenshots for work (as I did in this article). As you can imagine, I have a lot of content saved to this app and it can be difficult finding what I need just by scrolling through my folders.
In the example above, I was trying to find a photo I had taken at Niagara Falls, but I couldn’t remember if I had labeled it as such. So, I typed in “water” and received some helpful autocomplete suggestions on “water”-related words as well as photos that fit the description.
I would also put “Recent Search” results into this bucket. Here’s an example from Uber:
Before I even had a chance to type my search query in the Uber app, it displays my most recent search queries for me.
I think this would be especially useful for people who use ride-sharing services on a regular basis. Think about professionals who work in a city. Rather than own a car, they use Uber to transport to and from their office as well as client appointments. By providing a shortcut to recent trips in search results, the Uber app cuts down the time they spend booking a trip.
If you have enough data on your users and you have a way to anticipate their needs, autocomplete is a fantastic way to personalize search and improve the overall experience.
I think this time savings point is an important one to remember when designing search for mobile apps.
Unlike websites where longer times-on-page matter, that’s not always the case with mobile apps. Unless you’ve built a gaming or news app where users should spend lots of time engaging with the app on a daily basis, it’s not usually the amount of time spent inside the app that matters.
Your goal in building a mobile app is to retain users over longer periods, which means providing a meaningful experience while they’re inside it. A well-thought-out search function will greatly contribute to this as it gets users immediately to what they want to see, even if it means they leave the app just a few seconds later.
If you have an app that needs to get users in and out of it quickly, think about limiting search results as Ibotta has done:
While users certainly can enter any query they’d like, Ibotta makes it clear that the categories below are the only ones available to search from. This serves as both a reminder of what the app is capable of as well as a means for circumventing the search results that don’t matter to users.
Hotels.com also places limits on its search function:
As you can see here, users can’t just look for hotels throughout the country of Croatia. It’s just too broad of a search and one that Hotels.com shouldn’t have to provide. For one, it’s probably too taxing on the Hotels.com server to execute a query of that nature. Plus, it would provide a terrible experience for users. Imagine how many hotels would show up in that list of results.
By reining in what your users can search for and the results they can see, you can improve the overall experience while shortening the time it takes them to convert.
As you can see here, a search bar isn’t some throwaway design element. When your app promises a speedy and convenient experience to its users, a search bar can cut down on the time they have to spend inside it. It can also make the app a more valuable resource as it doesn’t require much work or effort to get to the desired content.
If we asked you to describe an effective digital marketing campaign, you might tout the value of strong design, ad targeting, or the benefits of conversion optimization. But even if your web and landing pages are aesthetically on point, it can mean nothing if you haven’t considered page speed. For context, if it takes more than three seconds for a page to load, just over half of visitors will leave it. Put another way, for every second of impatient agony you’re causing visitors with slow load times, you’re losing conversions and profit.
Beyond your bottom line, page speed also influences how your content ranks with Google. In July of this year, the search engine announced that speed will have a more prominent effect on the ranking of mobile searches. So if you want your landing pages and web pages to appear in the SERP (paid or search), you need them to be lightning-fast.
To paint a picture of why load time is so essential, we’ve collected seven stats about page speed. We’re currently doing some original research of our own on this, but for now, read on to learn why slow and steady doesn’t win the digital marketing race and use these fast facts to make the case for speeding up your landing pages.
When creating a landing page, you consider several factors (layout, content hierarchy, visuals, CTA, and more). But as Google encourages, page speed needs to be a priority too. Your visitors don’t like waiting—and their frustration has only grown since the 2015 survey linked above—so always consider load time (regardless of device) just as much as traditional design elements. Watch your image sizes and compress any that are borderline too heavy. Anything above 800kb is pushing your luck in the speed department.
(And that’s on simulated 4G and everything!) But that’s also just accounting for mobile—in general, pages can load much faster on desktop. According to the latest from Pingdom, for example, most web pages load in just 3.21 seconds. At a minimum, you should aim for a load time of three seconds or less—especially if you want to boost conversions.
When Akamai studied how mobile load times affected a client’s conversions, they discovered that 2.4 seconds was the sweet spot, averaging a peak mobile conversion rate of 1.9% during a 30-day span. On the flipside, when their client’s site loaded in 4.2 seconds, the average conversion rate dropped below 1%.
Ultimately, aiming for anywhere between 2.4 to 3 seconds on mobile and desktop is a smart move.
While you can definitely aim for quicker than five seconds, the point here is that the longer people spend on your pages, the more time they have to consume your content and actually convert. You work hard to build persuasive offers—so keep visitors on your landing pages by ensuring that they load quickly enough for them to actually see (and understand!) your key messaging.
Similar to Google’s stat about conversions dropping by 12% for every second of load time, Akamai comes to the table with another time-is-money figure. According to their research in 2017, one full second can decrease conversion rates by 70%! So, in addition to losing visitors, page speed is directly tied to losing a lot of potential revenue—something Mobify discovered when they decided to examine the effects of homepage load time. In its 2016 Q2 Mobile Insights Report, the online shopping platform revealed that every 100-millisecond decrease in load time worked out to a 1.11% increase in session-based conversion.
Hey, we’ve all been there. Even though faster speeds are constantly being offered to visitors (via telecom ads, internet providers, etc.), many websites still aren’t loading fast enough. That’s bad news for visitors, but great news for you in that there’s an opportunity to stand out if you speed up. SEMrush reports that “if your site loads in 1.7 seconds, it’s faster than approximately 75% of the web.” Use this as an opportunity for your brand to make a competitive move with websites and landing pages that load faster than most. It’s time to make speed a priority.
The online shopping experience isn’t just about website aesthetics or customer service; it’s about overall performance, which includes page speed and responsivity. This stat shows that something like a slow loading site can easily turn visitors away—sometimes for good.
A high bounce rate indicates visitors aren’t staying on your website for very long—I mean, sure they’re landing there, but they’re not consuming more content than the page they’re on right at that moment. And who knows how much of it?! This can mean they’re not clicking your CTA to a next step, nevermind learning about your key value prop.
It can be difficult to determine why, exactly, someone has left your landing page—poor audience targeting? Uninteresting content? Not enough multimedia? And if page speed is affecting bounce rate, you might begin to second guess your content. Save yourself some time (and confusion) by prioritizing page speed via solutions like Accelerated Mobile Pages (AMP).
Are slow loading pages affecting your digital marketing campaigns? Join our AMP beta and be one of the first to give your visitors a near-instant mobile experience.
Now, returning to our question about the most important thing to consider when designing a digital marketing campaign? Hopefully, with all of these stats in mind, you have a new perspective. Page speed is one of the first things visitors experience when they arrive on your site or landing page, and as load time continues to become a priority (for both mobile and desktop environments) it will only be more integral to the success of your online strategy—so you gotta hurry up!
Back in October, we were the first to claim that 2019 will be the year of page speed. We’ve got our eyes on the market and lemme tell you: Google is sending serious signals that it’s crunch time to deal with your slow pages.
Faster pages are a strategic marketing priority.
And sure enough, Google has made yet another change to uphold that prediction. In early November, they quietly rolled out the most significant update to a core performance tool we’ve seen to date, announcing the latest version of PageSpeed Insights.
So what does this update mean for marketers and their bottom line?
If you’ve used PageSpeed Insights to test page performance, it’s time to retest! Because your old speed scores don’t matter anymore. The good news is that you’ll have new data at your fingertips to help you speed up in ways that actually matter to your prospects and potential conversions.
Let’s take a closer look at this update and explore why it should play a role in your page speed strategy in 2019.
“You can’t improve what you don’t measure.”
PageSpeed Insights is easily Google’s most popular tool for measuring web performance.
When you look at the screenshot below, you can see why. It provides an easy-to-interpret color-coded scoring system that you don’t need an engineering degree to understand—red is bad, green is good. Your page is either fast, average, or slow. The closer to a perfect 100 you can get, the better. The scores also come with recommendations of what you can do to improve. It’s almost too easy to understand.
PageSpeed Insights v.4 (October 2019)
Earlier versions of PageSpeed Insights had some issues with how they reported performance. Simple results could be misleading, and experts soon discovered that implementing Google’s suggested optimizations didn’t necessarily line up with a better user experience. You might’ve gotten great scores, sure, but your pages weren’t always any faster or your visitors more engaged. Don’t even get me started on your conversion rates.
As Benjamin Estes over at Moz explains, “there are smarter ways to assess and improve site speed. A perfect score doesn’t guarantee a fast site.” Many experts like Estes began turning to more reliable tools—like GTMetrix, Pingdom, or Google’s own Lighthouse—to run more accurate performance audits. And who would blame them?
The latest version of PageSpeed Insights (v.5) fixes these issues by putting the focus where it should be: on user experience. This is a huge leap forward for marketers because it means that the tool is directly relevant to conversion optimization. It can help you get faster in ways that translate into higher engagement and conversion rates.
Lighthouse is excellent because it gives you a more accurate picture of how your landing pages perform with lab and field data. The lab data means you get results ASAP, whether you’ve seen traffic yet or not. This gives you a way to test and improve your pages before you point your ads at them.
New lab data from Lighthouse provides a much better picture of what a user experiences.
The Lighthouse engine behind PageSpeed Insights also brings more user-centric performance metrics with it, two of which are very important to your landing pages:
First Meaningful Paint (FMP) is the time it takes for the first valuable piece of content to load—usually a hero shot or video above the fold. It’s the “is this useful?” moment when you catch—or lose—a visitor’s attention. Even if the rest of your page loads later, it’s paramount that the first page elements appear as quickly as possible.
2. PageSpeed Insights Gives You Better Opportunities and Diagnostics
You can bid adieu to the short checklist of optimizations that experts like Ben Estes called out. Google has replaced the (moderately useful) feature with new opportunities and audits that will actually help you improve your visitor experience. These include new suggestions and estimated savings for each.
Your priorities should be much clearer:
Opportunities and Diagnostics in PageSpeed Insights
How your Unbounce Pages Stack Up
Faster pages earn you more traffic and better engagement. As a result, page speed has a major impact on your conversion rates and can even help you win more ad impressions for less. That’s why we’ve made page speed our priority into 2019.
To show how Unbounce stacks up in the real world, we chose to test an actual page created by one of our customers, Webistry, a digital marketing agency. Their “Tiny Homes of Maine” page is a real-world example.
Click here to expand.
We tested two versions of “Tiny Homes of Maine” using Google PageSpeed Insights v.5, running a minimum of three tests using the median results. The results below focus on the mobile scores:
Tiny Homes of Maine with Speed Boost
Speed Boost + Auto Image Optimizer
Next, we retested the Tiny Homes of Maine adding our upcoming Auto Image Optimizer into the mix. This new tool automatically optimizes your images as your page is published. You can fine-tune your settings, but we used the defaults here. Check out the mobile results:
Tiny Homes of Maine with Speed Boost + Auto Image Optimizer
The score jumped from a respectable 88 to an incredible 96 and, more meaningfully, we saw time to interactive improve from 4.4 sec to 2.7 sec. That’s 12.3 seconds faster than the average mobile web page, and 0.3 seconds faster than Google’s ideal 3 second load time.
Here we’ve shared the time to interactive speeds from both tests, for desktop and mobile, measured against the average web page:
Overall, when we tested, we saw Speed Boost and Auto Image Optimizer create a dramatic difference in performance without sacrificing visual appeal or complexity. We took a compelling page that converts well and upped the ante by serving it at blazing speeds. Whether on a mobile or desktop, the page loads in a way that significantly improves the visitor’s experience.
Speed Boost is already available to all our customers, and the Auto Image Optimizer is coming very soon. This means your own landing pages can start achieving speeds like the ones above right now. Read more about our page speed initiatives.
But hold up. What about AMP? You might already know about AMP (accelerated mobile) pages, which load almost instantly—like, less than half a second instantly. Not only do they lead to crazy engagement, but they eliminate waiting on even slow network connections. This makes your content accessible to everyone, including the 70% of global users still on 3G connections—or 70% of pedestrians on their phones while they wait at a crosswalk.
While AMP can be complicated to build, Unbounce’s drag-and-drop builder lets you create AMP in the same way you create all your landing pages. If you’d like to try it out for yourself, you can sign up for AMP beta which opens in January 2019.
For the speed test above, we decided to leave AMP out of it since AMP restricts some custom functionality and the page we used would’ve required a few design changes. It wouldn’t be apples to apples. But we’re pretty pumped to show you more of it in the next while.
Page Speed & Your Bottom Line
Seconds are one thing, but dollars are another. Google recognizes the direct impact that fast load times have on your bottom line, which is why they released the Impact Calculator in February 2018. This tool sheds more light on why providing accurate measurements is so important.
Let’s revisit our Tiny Homes landing page above as an example. Imagine this landing page gets 1,000 visitors a month, at a conversion rate of 3.5% (which is just slightly higher than the average Real Estate industry landing page in our Conversion Benchmark Report). If the conversion rate from lead to sale is 5%, and each conversion is worth an average of $54,000 (which is the mid-priced home on their landing page), then their average lead value is $2700.
Tiny Homes of Maine in the Impact Calculator
When we input those numbers into the Impact Calculator and improve their mobile page speed from 4.4 seconds to 2.8 seconds, as shown in the test above, the impact to revenue for this one page could be $52,580.
Heck yes, speed matters.
And if we forecast the near-instant speeds promised by Accelerated Mobile Pages (AMP), that page could see a potential annual revenue impact of more than $179,202 USD if it were to load in 1 second.
And that’s one landing page!
If you’ve been struggling with how to improve your page loading times, this latest version of PageSpeed Insights now gives you a much more meaningful picture of how you’re doing—and how to get faster.
You may not have considered speed a strategic priority, but when seconds can equate to tens of thousands of dollars, you need to. Try the Impact Calculator yourself or contact our sales team if you’d like to see what kind of revenue impact Unbounce landing pages can get you.
Mobile video optimization isn’t only about making videos play smoothly on smartphones of different screen sizes. Popular video hosting sites can help you to that end.
Vimeo and Wistia even offer responsive embedded code so that you can upload videos on your landing pages or blogs without worrying about the container size.
Even if your website is responsive, embedded videos with fixed width can give your visitors an unpleasant experience. And studies say that half of your users are less likely to engage with you if you give them a bad mobile experience. So, the next time you are planning to embed a video, go for responsive instead of “fixed width.”
Optimizing videos for mobile can be tricky. This article will not just help you fit your videos within the screen of a mobile device, but also help you improve these videos to increase conversions.
We have more video optimization hacks laid out for you below. Dig in.
And note that making videos playable on mobile is not your end goal. What matters more is conversion. Why are we even paying so much attention to mobile?
Mobile Video Optimization: Reasons
The reason we want you to be serious about mobile video optimization is because of these 2 stats:
Per these 2 points, you get the idea that mobile browsing is on the rise and people like to watch videos, more on the smartphone than on their desktop. Ergo thinking out a mobile-first strategy is crucial for your video marketing success.
Let us now move to how videos can be optimized to drive conversions on mobile devices:
Optimization Tip 1: A/B Test Vertical Video Ads
Most videos are designed to play in the landscape orientation. But let’s face it—we hold our phones vertically 94% of the time. So, it can be a hassle to flip your phone just to watch a video and then flip it back. Sounds like a waste of time, right? Many marketers thought so and are now A/B testing their ads with vertical videos.
Even a study from Facebook saw people preferring vertical video content:
– 79% of the novice vertical video consumers were in favor of the vertical video format.
– 65% of respondents applauded brands that are using vertical video for their advertising as “more innovative.”
So, prepare to contribute to this brave new world of vertical video content.
Optimization Tip 2: Use Native Video Uploads to Get More Views
Natively uploaded videos play automatically while you need to click to play videos that have been linked with other platforms. Facebook reports imply that you can achieve as much as 1055.41% higher average share rate with native videos compared to YouTube third-party video links.
So, don’t be a stranger to this native video tactic.
In one of the expert interviews, Matthew Vazquez also asserted the importance of uploading your video separately on YouTube, Vimeo, and Facebook each, and to use modified descriptions with strategic keyword density for all 3 uploads. Matthew says that “this is powerful when done right because now you’ve 3X your SEO potential.”
One of the best landing pages using an explainer video as the conversion bait was that of Dropbox. They had kept their landing page simple with one engaging video and a download button. Visitors watched the video, saw the benefit of using Dropbox, and proceeded to download it. It was a simple funnel, and the conversion rate was high. Reports say that Dropbox earned a million users and bagged a revenue of $48 million.
There are a few problems when it comes to adding a video to your landing page:
– To begin with, ensure that your landing page video is responsive. As we shared in the beginning, you can use Wistia or Vimeo’s responsive embedded code to get this done. These video-hosting platforms offer incredible analytics to help you monitor your video performance. You will get cool insights, such as at which point your viewers are dropping off, and will be able to use these to optimize the playback accordingly.
– Use a thumbnail that prompts visitors to play the video. Never put your landing page video on autoplay. That’s a no-no.
– Keep your video short; 60 to 90 seconds is the best. (Stats say 59% of viewers will watch your video to the end if it’s under a minute.) The idea is to ensure that your video isn’t too heavy and that it shouldn’t lag.
– Position the Call to Action (CTA) button next to the video. Also, ensure that the narrator ends the video with a verbal CTA message, or use text to highlight CTA on the end screen. Try doing both as well.
– Try user testing to see how your target audience interact with the video. Check if they click the video right away or if they are distracted by some other elements on your landing page.
Select these probable issues before spending on PPC campaigns and ads. After that’s done, you will have a landing page with a video that can get you the ROI.
Optimization Tip 4: Ensure that your video has a call to action at the end
Remember those “Please subscribe to our channel.” requests that video makers leave with at the end of the video? These work.
If you watch a video till the end, that means you already like it. So when the creator politely asks you to subscribe, there’s a good chance you would do it.
Call to actions are, therefore, important.
These instruct your users on the next course of action—what they should do after watching the video. So, don’t just put up your CTA message or link in the video description. Say it. Have the narrator of the video conclude your video with the call to action message.
You can also use the actor in the video to point to the CTA button at the end. (If it’s an animation video, use a hand illustration or directional cues.) You will notice that many YouTube video creators use this tactic to request the viewers to subscribe.
There’s another CTA hack. If you are using YouTube, it is its annotation and card features. You can also use these to pop up your CTA link on the screen itself. For mobile users, that makes navigation easier.
Optimization Tip 5: Use typography or subtitles to get a reaction
Your videos should make sense even when muted.
With platforms like Facebook and Twitter having the muted autoplay feature, you are bound to have viewers who will look at your video for a few seconds to determine if it’s worth watching. This means that you can’t afford to have videos that rely only on audio and narration.
Your video should make sense even without the audio or at least provide a context of what’s being presented. Mute your video and see if the idea is being conveyed even without the audio, or if the visual is powerful enough to make the viewers turn the volume up or put on their earphones (if they are at a public place).
Best way—try adding captions or subtitles or use typography animation. Either will help you grab viewer attention, engage them even with a muted video, and get a reaction.
Making your video play on mobile devices is not your end goal. As a marketer and business owner, what matters more is conversion. By using the above optimization hacks, you can get your videos to perform better on mobile.
Just remember the distinct phases of your buyer’s journey. A video designed for customers in the awareness phase may not be appealing to your audience in the evaluation phase or those hesitating at that purchase point.
So, create several types of videos to power your customer’s decision journey.
Conduct a survey acquiring information about your demographics if you want to be painfully precise; but for the most part, develop your content such that it is not inhibited by a small screen. Your videos should have details clearly presented so that these may not get missed out if viewed on a small screen.
This is just the tip of the iceberg. If you have some cool video optimization tips, please share your story in the comments below.
Fixed Elements And Overlays In XD: Incredibly Easy And Fun Methods For Your Prototypes
(This article is kindly sponsored by Adobe.) A fixed element is an object you set to a fixed position on the artboard, allowing other items to scroll underneath. This way, you get a realistic simulation of scrolling on desktop and mobile. With the new overlay feature, you can simulate interactions such as lightbox effects and submenus.
How do famous brands use fixed elements and overlays? Well, let’s take a look at some examples to get some inspiration first.
In this tutorial, we will learn how to set a menu bar as a fixed element and how to apply an overlay transition in a prototype, to simulate a menu opening from the click of a button. Both examples will be done in a mobile template, so that we can see our simulation in action directly on our mobile device. I’ve also included an Illustrator file with icons, which you can use to set up your examples quickly.
Let’s get started.
Preparing The Mobile Template
Open Adobe Xd, and choose the “iPhone 6/7/8 Plus” template. Then, go to File → Save As and choose a name to save your file (mine is mobile.xd).
Let’s create a restaurant app in which people can select what to order from a list of food.
We will create two home layouts. The first one will be a long page, which we will use to see how fixed navigation works. The second will have a full-screen image, and the user will be able to click and open a menu bar that overlays the home screen.
To get started, click on the artboard icon on the left side, and click to the right of your current artboard. This will create a second identical artboard, near the first one.
Let’s begin to design our elements, starting with the navigation bar. Click on the Rectangle tool (R) and draw a shape 414 pixels wide and 48 pixels tall. Set its color as #DE4F4F.
I’ve prepared some icons in Illustrator to use in our layout. Just open the Illustrator file I’ve provided, and drag and drop the icons in your library, as shown below:
In doing so, your icons will be automatically uploaded to your Adobe XD library, too.
To learn more about how to use libraries in different apps, read my earlier article, in which I go over some examples of how to add icons and elements to a library (in Illustrator, for instance) and then access them by opening that library in other apps (XD, in this case).
Once you have added the icons, open your XD library. You should see the icons in place:
Drag and drop the icons on your artboard, as shown below. Position them, and make sure they are all about 25 pixels wide.
Because we need our icons to be white, we have to modify these. We can directly modify them in the library, as demonstrated in my previous tutorial. With that done, we’ll see them updated in XD directly, without having to drag them from the library again.
Now that the icons we want are in place, let’s create a logo. Let’s call this app “Gusto”. We’ll simply use the Text tool to add it. (I’m using the Leckerli One font here, but feel free to use whichever you like.) Align the logo to the middle of the navigation bar by clicking “Align center (horizontally)” in the right sidebar.
Group all of the navigation elements together, and call the group “Menu”. To do this, select all elements in the left panel, right-click and choose “Group”.
Let’s add a beautiful hero image. I selected one from Pexels. Drag it on your artboard, and resize its height to 380 pixels.
Now, click on Rectangle tool (R), and draw a rectangle the same size as the hero image, and place it on the image. Set a gradient for the rectangle’s color, using the values shown in the image below.
(If you’d like more information about gradients, feel free to see my previous tutorial on how to apply them in XD.)
Insert some white text on the hero image and a circle for a button. Place a little circle with a number on the cart icon as well; we will need it later.
Next, let’s increase the artboard’s height. We have to do that in order to insert new elements and to create the scrolling simulation.
After double-clicking on the artboard, set its height to 1265 pixels. Be sure that “Scrolling” is set to “Vertical” and that the “Viewport Height” is set to 736 pixels. A little blue marker will allow you to set the scrolling boundary towards the bottom of the artboard, as seen below:
Let’s add in our content: Gusto’s mouthwatering menu. Click on the Rectangle tool (R) to create a rectangle for the picture that we will add.
Drag and drop a picture directly into the box we just created; the image will automatically fit in it. Click on it once, and drag the little white circle from an angle inwards, in order to round all of the angles. Their values should be around 25, as shown in the picture below. Get rid of the border by unchecking the border value in the right sidebar.
Click on the Text tool (T), and write a title on the right side of the image. I chose Lato as the font, at 14 pixels. Feel free to use another font, but maintain the 14-pixel size.
Grab the Text tool (T) again, and write some lines for the description (Lato, 10 pixels) and for the price (Lato, 16 pixels).
Take the Rectangle tool (R) and draw a rectangle of 100 by 30 pixels. Color it with the same orange we used on the button for the hero image; add the text “Add to Cart” with the Text tool (T); and add the cart icon from the library. All of these steps are covered in the short video below:
Finally, click on “Repeat Grid” to create a grid for this section. Once that’s done, we can change images and text easily, as shown in the video below:
If you want to learn more about how to create grids, follow my tutorial.
Finally, let’s add a rectangle for the footer, with the text “Gusto” in the center. Set the rectangle’s fill color to #211919.
Yes! We’ve completed the first template design. Let’s set up our second template before we begin prototyping.
For our second mobile layout, just copy and paste the navigation and hero section from the first layout, and size the hero image to be full screen. Then, add a “Try Now” button to it.
In the short video below, I show you how to copy and paste elements into the second artboard, create a new button with the Rectangle tool (R) and write text on it with the Text tool (T).
Excellent! Let’s move on and create our prototypes.
Setting Fixed Elements
We want to make the top navigation of our layout fixed, making it stick to its position as we scroll the artboard.
Click on your “Menu” group to select it, and select “Fixed Position” in the right sidebar.
Important: In order for all elements to scroll under the menu, the menu should be on top of all other elements. Simply place the menu folder at the top, in the left sidebar.
Now, to see your fixed navigation in action, simply click on the “Desktop Preview” button and try scrolling. You should see this:
Tremendously simple, isn’t it?
Setting Overlay Elements
To see how overlays work in XD, we first need to create the elements that will be overlaid. When you click an item in the menu, what would you expect to happen? Exactly: A submenu should appear.
Let’s create three different submenus, like the ones in the image below, using the Rectangle tool (R). I chose a rectangle because the menu will overlay the screen, so it will cover not the whole artboard but just a part of it.
Follow the video below to see how I created the three overlay menus. You will see that I used the Rectangle tool (R), Line tool (L) and Text tool (T). We’re using rectangles to create the menu backgrounds because we need an object to overlay the screen. I’ve included the icons in the Adobe Illustrator file.
Below, you’ll see how I use “Repeat Grid” and how I modify elements inside of it.
Here is the final result:
We will work on the second home layout at this point.
Set the visual mode to “Prototype”, selecting it from the top left of the screen.
Next, double-click on the little hamburger menu icon, and drag and drop the little blue arrow onto the “Overlay 1” artboard. When the popup window appears, choose “Overlay” and “Slide right”. Then, click the “Desktop Preview” button to see it in action.
Let’s do the same thing with the user icon and cart icon. Double-click on the user icon in Prototype mode, and drag and drop the little blue arrow onto the “Overlay 2” artboard. When the popup window appears, choose “Overlay” and “Slide left”. Then, click the “Desktop Preview” button to see it in action.
Now, double-click on the cart icon in Prototype mode, and drag and drop the little blue arrow onto the “Overlay 3” artboard. When the popup windows appears, choose “Overlay” and “Slide left”. Click the “Desktop Preview” button again to see it work.
We’re done! These great new features are super-easy to learn, and they’ll add a new level of interactivity simulation to your prototypes.
Quick tip: Want to preview the layout on your phone? Just upload your XD file to Creative Cloud, download the XD app for mobile, and open your document.
Here’s what we have learned in this tutorial:
set and create mobile layouts and elements,
set fixed elements,
use overlays to simulate a click-to-open submenu.
Where would you use fixed elements or overlays? Feel free to share your examples in the comments below!
Welcome! For those of you just tuning in: Last week I attended Klaviyo: BOS, a two-day summit focused on growth tactics and business strategy for online merchants and ecommerce brands. Session topics ranged from Facebook Messenger bots and segmentation to email design and marketing automation. I took a ton of very squiggly, sometimes illegible notes and thought it would be a shame to keep them on paper, so I sat down and started writing a blog post titled “Expert SEO and CRO Tips From Klaviyo’s Ecommerce Summit.” I was at about 2,000 words when I had to take a break, so here…
Earlier this year, a man drove his car into a lake after following directions from a smartphone app that helps drivers navigate by issuing turn-by-turn directions. Unfortunately, the app’s programming did not include instructions to avoid roads that turn into boat launches.
From the perspective of the app, it did exactly what it was programmed to do, i.e. to find the most optimal route from point A to point B given the information made available to it. From the perspective of the man, it failed him by not taking the real world into account.
The same principle applies for accessibility testing.
Designing For Accessibility And Inclusion
The more inclusive you are to the needs of your users, the more accessible your design is. Let’s take a closer look at the different lenses of accessibility through which you can refine your designs. Read article →
Automated Accessibility Testing
I am going to assume that you’re reading this article because you’re interested in learning how to test your websites and web apps to ensure they’re accessible. If you want to learn more about why accessibility is necessary, the topic has been covered extensively elsewhere.
Automated accessibility testing is a process where you use a series of scripts to test for the presence, or lack of certain conditions in code. These conditions are dictated by the Web Content Accessibility Guidelines (WCAG), a standard by the W3C that outlines how to make digital experiences accessible.
For example, an automated accessibility test might check to see if the tabindex attribute is present and if its value is greater than0. The pseudocode would be something like:
Failures can then be collected and used to generate reports that disclose the number, and severity of accessibility issues. Certain automated accessibility products can also integrate as a Continuous Integration or Continuous Deployment (CI/CD) tool, presenting just-in-time warnings to developers when they attempt to add code to a central repository.
These automated programs are incredible resources. Modern websites and web apps are complicated things that involve hundreds of states, thousands of lines of code, and complicated multi-screen interactions. It’d be absurd to expect a human (or a team of humans) to mind all the code controlling every possible permutation of the site, to say nothing of things like regressions, software rot, and A/B tests.
Automation really shines here. It can repeatedly and tirelessly pour over these details with perfect memory, at a rate far faster than any human is capable of.
Automated accessibility tests aren’t a turnkey solution, nor are they a silver bullet. There are some limitations to keep in mind when using them.
Thinking To Think Of Things
One of both the best and worst aspects of the web is that there are many different ways to implement a solution to a problem. While this flexibility has kept the web robust and adaptable and ensured it outlived other competing technologies, it also means that you’ll sometimes see code that is, um, creatively implemented.
For example, the automated accessibility testing site Tenon.io wisely includes a rule that checks to see if a form element has both a label element and an aria-label associated with it, and if the text strings for both declarations differ. If they do, it will flag it as an issue, as the visible label may be different than what someone would hear if they were navigating using a screen reader.
If you’re not using a testing service that includes this rule, it won’t be reported. The code will still “pass”, but it’s passing by omission, not because it’s actually accessible.
Some automated accessibility tests cannot parse the various states of interactive content. Critical parts of the user interface are effectively invisible to automation unless the test is run when the content is in an active, selected, or disabled state.
By interactive content, I mean things that the user has yet to take action on, or aren’t present when the page loads. Unopened modals, collapsed accordions, hidden tab content and carousel slides are all examples.
It takes sophisticated software to automatically test the various states of every component within a single screen, let alone across an entire web app or website. While it is possible to augment testing software with automated accessibility checks, it is very resource-intensive, usually requiring a dedicated team of engineers to set up and maintain.
Just having the presence of ARIA does not guarantee that it will automatically make something accessible. Unfortunately, and in spite of its first rule of use, ARIA is commonly misunderstood, and consequently abused. A lot of off-the-shelf code has this problem, perpetuating the issue.
<!-- Never do this -->
To further complicate the issue, support for ARIA is varied across browsers. While an attribute may be used appropriately, the browser may not communicate the declared role, property, or state to assistive technology.
There is also the scenario where ARIA can be applied to an element and be valid from a technical standpoint, yet be unusable from an assistive technology perspective. For example:
Tired of unevenly cooked asparagus? Try this tip from the world’s oldest cookbook.
Headings — especially first-level headings — are vital in communicating the purpose of a page. If a person is using assistive technology to navigate, the aria-hidden declaration applied to the h1 element will make it difficult for them to quickly determine the page’s purpose. It will force them to navigate around the rest of the page to gain context, an annoying and labor-intensive process.
Some automated accessibility tests may scan the code and not report an error since the syntax itself is valid. The automation has no way of knowing the greater context of the declaration’s use.
This isn’t to say you should completely avoid using ARIA! When authored with care and deliberation, ARIA can fix the gaps in accessibility that sometimes plague complicated interactions; it provides some much-needed context to the people who rely on assistive technology.
As the soggy car demonstrates, computers are awful at understanding the overall situation of the outside world. It’s up to us humans to be the ultimate arbiters in determining if what the computer spits out is useful or not.
Before we discuss how to provide appropriate context, there are a few common misunderstandings about accessibility work that need to be addressed:
Second, accessibility is more than just screen readers. The rules outlined in the Web Content Accessibility Guidelines ensure that the largest number of people can read and operate technology, regardless of ability or circumstance.
Third, disabilities can be conditional and can be brought about by your environment. It can be a short-term thing, like rain on your glasses, sleep deprivation, or an allergies-induced migraine. It can also be longer-term, such as a debilitating illness, broken limb, or a depressive episode. Multiple, compounding conditions can (and do) affect individuals.
That all being said, many accessibility fixes that help screen readers work properly also benefit other assistive technologies.
Get Your Feet Wet
Knowing where to begin can be overwhelming. Consider Michiel Bijl’s great advice:
“Before you release a website, tab through it. If you cannot see where you are on the page after each tab; you're not finished yet. #a11y
Tab through a few of the main user flows on your website or web app to determine if all interactive components’ focus states are visually apparent, and if they can be activated via keyboard input. If there’s something you can click or tap on that isn’t getting highlighted when receiving keyboard focus, take note of it. Also pay attention to the order interactive components are highlighted when focused — it should match the reading order of the site.
If you need a baseline to compare your testing to, Dave Rupert has an excellent project called A11Y Nutrition Cards, which outlines expected behavior for common interactive components. In addition, Scott O’Hara maintains a project called a11y Styled Form Controls. This project provides examples of components such as switches, checkboxes, and radio buttons that have well-tested and documented support for assistive technology. A clever reader might use one of these resources to help them try out the other!
The Fourth Myth
With that out of the way, I’m going to share a fourth myth with you: not every assistive technology user is a power user. Like with any other piece of software, there’s a learning curve involved.
In her post about Aaptiv’s redesign, Lisa Zhu discovers that their initial accessibility fix wasn’t intuitive. While their first implementation was “technically” correct, it didn’t line up with how people who rely on VoiceOver actually use their devices. A second solution simplified the interaction to better align with their expectations.
Don’t assume that just because something hypothetically functions that it’s actually usable. Trust your gut: if it feels especially awkward, cumbersome, or tedious to operate for you, chances are it’ll be for others.
Dive Right In
While not every accessibility issue is a screen reader issue, you should still get in the habit of testing your site with one. Not an emulator, simulator, or some other proxy solution.
If you find yourself struggling to operate a complicated interactive component using basic screen reader commands, it’s probably a sign that the component needs to be simplified. Chances are that the simplification will help non-assistive technology users as well. Good design benefits everyone!
The same goes for navigation. If it’s difficult to move around the website or web app, it’s probably a sign that you need to update your heading structure and landmark roles. Both of these features are used by assistive technology to quickly and efficiently navigate.
Another good thing to review is the text content used to describe your links. Hopping from link to link is another common assistive technology navigation technique; some screen readers can even generate a list of all link content on the page:
“Think before you link! Your "helpful" click here links look like this to a screen reader user. ALT = JAWS links list”
When navigating using an ordered list devoid of the surrounding non-link content, avoiding ambiguous terms like “click here” or “more info” can go a long way to ensuring a person can understand the overall meaning of the page. As a bonus, it’ll help alleviate cognitive concerns for everyone, as you are more accurately explaining what a user should expect after activating a link.
How To Test
Each screen reader has a different approach to how it announces content. This is intentional. It’s a balancing act between the product’s features, the operating system it is installed on, the form factor it is available in, and the types of input it can receive.
The Browser Wars taught us the folly of developing for only one browser. Similarly, we should not cater to a single screen reader. It is important to note that many people rely exclusively on a specific screen reader and browser combination — by circumstance, preference, or necessity’making this all the more important. However, there is a caveat: each screen reader works better when used with a specific browser, typically the one that allows it access to the greatest amount of accessibility API information.
All of these screen readers can be used for free, provided you have the hardware. You can also virtualize that hardware, either for free or on the cheap.
Automated accessibility tests should be your first line of defense. They will help you catch a great deal of nitpicky, easily-preventable errors before they get committed. Repeated errors may also signal problems in template logic, where one upstream tweak can fix multiple pages. Identifying and resolving these issues allows you to spend your valuable manual testing time much more wisely.
It may also be helpful to log accessibility issues in a place where people can collaborate, such as Google Sheets. Quantifying the frequency and severity of errors can lead to good things like updated documentation, opportunities for lunch and learn education, and other healthy changes to organizational workflow.
The two most popular screen readers on Windows are JAWS and NVDA.
JAWS (Job Access With Speech) is the most popular and feature-rich screen reader on the market. It works best with Firefox and Chrome, with concessions for supporting Internet Explorer. Although it is pay software, it can be operated in full in demo mode for 40 minutes at a time (this should be more than sufficient to perform basic testing).
Google recently folded TalkBack, their mobile screen reader, into a larger collection of accessibility services called the Android Accessibility Suite. It works best with Mobile Chrome. While many Android apps are notoriously inaccessible, it is still worth testing on this platform. Android’s growing presence in emerging markets, as well as increasing internet use amongst elderly and lower-income demographics, should give pause for consideration.
If you do not require the use of assistive technology on a frequent basis then you do not fully understand how the people who do interact with the web.
Much like traditional user testing, being too close to the thing you created may cloud your judgment. Empathy exercises are a good way to become aware of the problem space, but you should not use yourself as a litmus test for whether the entire experience is truly accessible. You are not the expert.
If your product serves a huge population of users, if its core base of users trends towards having a higher probability of disability conditions (specialized product, elderly populations, foreign language speakers, etc.), and/or if it is required to be compliant by law, I would strongly encourage allocating a portion of your budget for testing by people with disabilities.
“At what point does your organisation stop supporting a browser in terms of % usage? 18% of the global pop. have an #Accessibility requirement, 2% people have a colour vision deficient. But you consider 2% IE usage support more important? Support everyone be inclusive.”
This isn’t to say you should completely delegate the responsibility to these testers. Much as how automated accessibility testing can detect smaller issues to remove, a first round of basic manual testing helps professional testers focus their efforts on the complicated interactions you need an expert’s opinion on. In addition to optimizing the value of their time, it helps to get you more comfortable triaging. It is also a professional courtesy, plain and simple.
There are a few companies that perform manual testing by people with disabilities:
We also need to acknowledge the other large barrier to accessible sites that can’t be automated away: poor user experience.
User experience can make or break a product. Your code can compile perfectly, your time to first paint can be lightning quick, and your Webpack setup can be beyond reproach. All this is irrelevant if the end result is unusable. User experience encompasses all users, including those who navigate with the aid of assistive technology.
If a person cannot operate your website or web app, they’ll abandon it and not think twice. If they are forced to use your site to get a service unavailable by other means, there’s a growing precedent for taking legal action (and rightly so).
As a discipline, user experience can be roughly divided into two parts: how something looks and how it behaves They’re intrinsically interlinked concepts — work on either may affect both. While accessible design is a topic unto itself, there are some big-picture things we can keep in mind when approaching accessible user experiences from a testing perspective:
How It Looks
The WCAG does a great job covering a lot of the basics of good design. Color contrast, font size, user-facing state: a lot of these things can be targeted by automation. What you should pay attention to is all the atomic, difficult to quantify bits that compound to create your designs. Things like the words you choose, the fonts you use to display them, the spacing between things, affordances for interaction, the way you handle your breakpoints, etc.
“A good font should tell you: the difference between m and rn the difference between I and l the difference between O and 0.”
It’s one of those “an ounce of prevention is worth a pound of cure” situations. Smart, accessible defaults can save countless time and money down the line. Lean and mean startups all the way up to multinational conglomerates value efficient use of resources, and this is one of those places where you can really capitalize on that. Put your basic design patterns — say collected in something like a mood board or living style guide — in front of people early and often to see if your designed intent is clear.
How It Behaves
An enticing color palette and collection of thoughtfully-curated stock photography only go so far. Eventually, you’re going to have to synthesize all your design decisions to create something that addresses a need.
Behavior can be as small as a microinteraction, or as large as finding a product and purchasing it. What’s important here is to make sure that all the barriers to a person trying to accomplish the task at hand are removed.
If you’re using personas, don’t create a separate persona for a user with a disability. Instead, blend accessibility considerations into your existing ones. As a persona is an abstracted representation of the types of users you want to cater to, you want to make sure the kinds of conditions they may be experiencing are included. Disability conditions aren’t limited to just physical impairments, either. Things like a metered data plan, non-native language, or anxiety are all worth integrating.
“When looking at your site's analytics, remember that if you don't see many users on lower end phones or from more remote areas, it's not because they aren't a target for your product or service. It is because your mobile experience sucks. As a developer, it's your job to fix it.”
User testing, ideally simulating conditions as close to what a person would be doing in the real world (including their individual device preferences and presence of assistive technology), is also key. Verifying that people are actually able to make the logical leaps necessary to operate your interface addresses a lot of cognitive concerns, a difficult-to-quantify yet vital thing to accommodate.
We Shape Our Tools, Our Tools Shape Us
Our tool use corresponds to the kind of work we do: Carpenters drive nails with hammers, chefs cook using skillets, surgeons cut with scalpels. It’s a self-reinforcing phenomenon, and it tends to lead to over-categorization.
Sometimes this over-categorization gets in the way of us remembering to consider the real world. A surgeon might have a carpentry hobby; a chef might be a retired veterinarian. It’s important to understand that accessibility is everyone’s responsibility, and there are many paths to making our websites and web apps the best they can be for everyone. To paraphrase Mikey Ilagan, accessibility is a holistic practice, essential to some but useful to all.
Used with discretion, ARIA is a very good tool to have at our disposal. We shouldn’t shy away from using it, provided we understand the how and why behind why they work.
The same goes for automated accessibility tests, as well as GPS apps. They’re great tools to have, just get to know the terrain a little bit first.
Have you ever faced down a giant table or spreadsheet of data and thought, “I have no idea what to do with this”? As marketers we’ve all probably had those deer-in-the-headlights moments once or twice, where we’ve floundered to figure out what the hell we’re looking at. Crazy Egg was built on the premise of simplicity and ease of use, for those that I fondly like to call “Google Analytics-averse” – but there’s always room for improvement when it comes to helping folks switch from analysis to action mode. Whether you’re a UX designer, small business owner, SEO expert or…
We live in a fast-paced world. People want things as quickly as possible — and they’re unhappy when something takes too long. Website speed optimization takes away one barrier between you and your audience. Think about the last time you encountered a slow-loading website. You might have closed out the browser tab entirely or felt less inclined to patronize the site once it finally loaded. Google understands that consumers want fast access to information, products, and services. Consequently, it rewards websites that load quickly. Let’s take a look at a few ways in which you can use website speed optimization…