A Journey of One Thousand Miles: Different styles and uses of progress indicators

One feature, common to nearly every process (and especially most processes in ecommerce), is something that indicates progress - a map, if you will, that shows your current location relative to the destination. Even our Instant Pot has a display that indicates when pressure builds and releases. But, just as every process is different, there should be different techniques that indicate the process and the current state.

One of the most common uses of progress indicators is in multi-page forms - that's certainly where I've had the most exposure to them. In general, they're intended to reduce cognitive load in a process, and they can either succeed or fail, often with significant results.

In the Web Accessibility Initiative section for multi-page forms, several different methods for identifying progress are put forward. The methods used to indicate progress for multi-page forms can be briefly described as (a) landmark content, (b) a progressbar, and (c) a step-by-step indicator - and I'll take each of them in turn to discuss how they might be used and whether or not they can, or should, apply to other types of progress.

Landmark Content

The use of landmark content to identify progress is almost always a good method, especially when - as the first approach identified by the WAI - updating the title element is used. As a general rule, assistive technology will announce changes to the page title. The other approach in the landmark content method, updating the main heading - i.e. the h1 element - is also a good approach as many users navigate using headings and it is, or at least should be, more visible than the page title. Rather than use one of these approaches, use both.

Of course, there are disadvantages to using this method. Neither approach - updating the page title or updating the main heading - is likely to be sufficient if the user has scrolled far enough. Updates are likely to be noticed only by users who have the main heading in their field of vision or are using assistive technology that announces changes. Also, both approaches in this method update content, so not all accessibility is improved - the user still must either read, or have assistive technology that will read, the updated content.

A Progressbar

Progressbar
(from a progress element, rendered in Chrome)

HTML5 offers a progress element that takes a max attribute and a value attribute to draw a visual representation. The progress element takes content, which must be updated, as in <progress max="7" value="1">Step 1 of 7</progress>. However, in some platforms, a progress bar is animated in a way that would violate the Web Content Authoring Guidelines Success Criterion 2.2.2, an A-level criterion.

Like several of the additions in HTML5, the progress element is not very accessible, so it's still recommended a better widget - one that uses the progressbar role with aria-valuemin, aria-valuemax, and aria-valuenow - be used, but be advised that automatic updates to the value in a progressbar role are not well-defined.

The progressbar, whether implemented using the HTML5 progress element or a widget that uses the progressbar role, may be sufficient if the progress reflected is proportional, such as a file transfer showing the number of bytes transferred. The interface is not well-suited to processes where one or more steps is larger, or takes more time, than others.

A Step-by-step Indicator

Step-by-step Indicator

The third method - a step-by-step indicator - can help users orient themselves in multiple ways. First, the user should be able to clearly see how much progress they've made, whether the progress within each segment is proportional or not. Second, the content should reflect not only steps already completed but the current step, and not-started, or upcoming, steps. In this method, there are three common approaches we can use, and each will apply to different cases.

Fixed-Journey Indicator

The basic step-by-step indicator presented for multi-page forms by the WAI is an ordered list, with list items that have visually hidden content to indicate which item is completed or current. This is likely sufficient, if the progress is a consecutive series of unidirectional steps under the control of the user - although the WAI example should be updated to reflect capabilities available in the ARIA states and properties.

Breadcrumbs

If, progress is bidirectional or the user may complete steps in a non-consecutive manner, the interface should be a navigational one which allows the user to choose the step they'd like to complete. This step-by-step indicator becomes more complex as it not only needs to include completed, current, and not-started states but also accessible navigation between the steps. This sort of navigational, step-by-step indicator is often called a breadcrumb because it's more than just a progress indicator.

This type of progress indicator should especially be used for multi-page forms if those forms cause legal commitments or financial transactions to occur or update user-provided data that has been stored to help meet WCAG Success Criterion 3.3.4 as it aids in the review, confirmation, and correction of information.

Status Indicator

The third type of step-by-step indicator is a status indicator. The status indicator is still, semantically, an ordered list, but a status may switch in a non-consecutive manner and the status is likely to be outside the control of the user. An example of this might be a payment transaction that moves from pending to authorizing to completed or a document retrieval that moves from requesting to receiving to received to loaded. In either of these cases, an intermediate step may be skipped, e.g., the payment may appear to move from pending to completed or the document may move from receiving to loaded.

This type of progress indicator is perhaps the most complex, because the user interface is not really a progress indicator but a status indicator (hence the name). The upcoming statuses need not be announced because their inclusion is likely to reduce cognitive accessibility - the user can do nothing to either prevent or encourage the move to that state. Further, announcing which of the items in the list is current lacks the context that the visual interface has, so identifying completed and current items is a little more complex.

It is also important to note that because this indicator is auto-updating and representing something outside the control of the user, it is critical that it only be used for those activities that are essential. If the interface is used for a part of an activity that is non-essential, the auto-update feature without the ability to pause, stop, or hide the update will violate WCAG Success Criterion 2.2.2, just as the HTML5 progress element would.

Conclusion

Any of the four different types of progress indicators - a progressbar, a fixed-journey indicator, breadcrumbs, or a status indicator - can be sufficient to describe process. While they have areas of overlap, each has a specific interface that leads to a design pattern and accessibility features.

In the very near future, I will be launching a gitbook called Think A11y that will be covering components like this, including HTML, CSS, and JavaScript, in an effort to put my accessibility resources in one location. This blog will still cover accessibility issues from time to time, but hopefully this new approach will make my electronic life a little easier to manage and share. In the meantime...

Happy coding.

Open Sesame: A better password experience

Password inputs are ubiquitous, but they're often poorly designed. Not because they're not announced or lack security features to prevent someone looking over your shoulder and discerning your password. Instead, it's the user experience that's poorly designed.

In order to be as secure as possible, we're encouraged to have strong passwords, but each site's idea of what makes a password strong varies and often users are left to guess what the requirements are until after they've tried to enter a password and it has failed the hidden validation rules. In many cases the only clue users have is a strength indicator that slides from weak to strong.

To improve the user's experience, I'm going to suggest you add a list of the hidden validation rules, something like the following.

Password

• At least one lowercase letter is required
• At least one uppercase letter is required
• At least one number is required
• At least one special character from the following list is required: !, @, #, $, %, ^, &, or *

Additionally, it is going to be tempting to make these hidden validation rules present only during onboarding, when the user is creating an account. This practice will lead to unnecessary frustration when users try to login but cannot remember their password. The addition of the list of rules to the interface gives additional clues that can trigger a remembered password, so add the validation rules description list any time a user needs to input a password.

Additionally, when using this approach, one might consider hiding these rules behind an accordion or tooltip that is only displayed by some user action; however, I would recommend against that approach as it reduces the accessibility this practice improves.

Another word about accessibility here, and this is best explained through markup. As you will notice in the markup below, which creates the list, uses the aria-describedby attribute to tie the validation rules to the input.

HTML

<label for="password">Password</label> <input aria-describedby="required-features" id="password" type="password" /> <ul id="required-features">   <li class="missing">At least one lowercase letter is required</li>   <li class="missing">At least one uppercase letter is required</li>   <li class="missing">At least one number is required</li>   <li class="missing">At least one special character from the following list is required: !, @, #, $, %, ^, &amp;, or *</li> </ul>

At this point it may be tempting to include an icon - something like <li><i class="missing"></i>At least one lowercase letter is required<li> - however, you should not do this, because it causes a fragmentation issue, which is when the accessible name of an item is generated by the first element rather than appending all elements together. Instead, use the listing as is and use a CSS pseudoelement ::before to generate content, otherwise you're likely to hear "warning sign" repeated for each item in the list and the remainder of the text will not be announced. There are ways around this, of course, but it's generally best to keep to the simplest method.

In the near future, this pattern will be exposed in the roking react repo with automatic updates to the list as the validation tests pass. As with other components in the repo, accessibility issues will be resolved to provide the best possible user interface for everyone. Of course, you're encouraged to develop using this pattern in a way that meets your needs, even without using the roking react repo.

Happy coding.

Getting the light show started

Anyone who's followed me for very long knows that one of my big concerns is accessibility. Today I'm going to tell you exactly how you can violate accessibility rules and possibly trigger epileptic seizures in a portion of the population at the same time. I'm sharing this information because this should NEVER happen, and yet it does (this means I've seen it in the wild).

Let's take, as a hypothetical case, a design where when you hover over something you want to show a callout - a very common design. In browser-based terms, there are two ways you can handle hovering interactions - using the CSS pseudoclass (which you should only use with focus and active, by the way) and with JavaScript using the mouse events.

Using CSS it's relatively straightforward - add the two elements (we'll call them the target and callout) to the DOM as siblings, placing the callout after the target, and hide the callout by default and use a sibling selector with the hover pseudoclass to show the callout. By the way, this shifts the show/hide functionality to the GPU and keeps it out of the script stack - which means it'll provide better performance. This is the best way to implement this little trick.

Unfortunately, more than a few engineers in our industry don't like CSS and prefer to do everything in JavaScript. In this case, we would still have the two DOM nodes and we would add event listeners to show the callout when we mouseover the target and hide the callout when we mouseover it. This method keeps the show/hide in the script stack, meaning it'll likely get janky at some point.

Here's where the bad stuff comes into play.

If the target and callout overlap (they way they sometimes will - especially in a responsive design), they will 'flash' as the 'hover' events fire on each element. This will be bad, very bad, especially if there is significant contrast between the colors, unless you're trying to simulate a nightclub or light show and don't really care about the likelihood of triggering photosensitive epilepsy.

If you want to see how this works, run the code samples below in a browser, but be warned, the target/callout flashes more than three times per second.

CSS

<!DOCTYPE html> <html> <body> <style type="text/css"> #callout, #target {   border: 1px solid black;   height: 10rem;   left: 20px;   position: absolute;   top: 100px;   width: 90%; } #callout {   z-index: -1; } #target:hover + #callout {   z-index: 10; } </style> <div id="parent">   <p id="target" style="background-color: #0f0;">target</p>   <p id="callout" style="background-color: #f00;">callout</p> </div> </body> </html>

JavaScript

<!DOCTYPE html> <html> <body> <style type="text/css"> #callout, #target {   border: 1px solid black;   height: 10rem;   left: 20px;   position: absolute;   top: 100px;   width: 90%; } #callout {   z-index: -1; } </style>
<div id="parent"> <p id="target" style="background-color: #0f0;">target</p> <p id="callout" style="background-color: #f00;">callout</p> </div>
<script> var callout = document.getElementById('callout'); var target = document.getElementById('target'); target.addEventListener('mouseover', function() {     callout.style.zIndex = '10'; }); callout.addEventListener('mouseover', function() {     callout.style.zIndex = '-1'; }); </script> </body> </html>

Notes

1. A callout is those little bubbles that have a triangular-ish thing connecting the bubble to an item as a visual context clue.
2. The events mouseenter, mouseleave, mousemove, mouseout,  and mouseover are the events applicable to a 'hover'

Print It!

Several years ago, Smashing Magazine did an article called 5 Powerful Tips and Tricks for Print Style Sheets, but we don't often remember print stylesheets today because, let's be honest, people don't generally print things anymore - at most, we save them to PDF on our device - but it is still an important part of the design of the interface.

Print stylesheets, however, can be pretty powerful, and there are a lot of times we still want a hardcopy of something we've worked on. In the financial services sector, we see this fairly often. People want a record of what they've signed up for - especially when it comes to paying interest. It doesn't really matter if the "hardcopy" is a PDF or a tree-killing version you can hold in your hands, we want it to look official.

There are a few things you'll want to keep in mind when printing, but generally, read the Smashing Magazine article I've linked above. One issue the Smashing Magazine article doesn't go into detail about is font size. Don't mess about with the font size. There are loads of posts about accessibility and font size and how to use rem or em rather than px on a web page - the same holds true for printed versions. You don't want someone getting the small print version when what they see on the screen is large print.

One thing that deserves a special callout - the Smashing Magazine article talks about expanding links and this is very important. In printed versions the user will not (generally) have the ability to hover over or follow a link, so make sure the appropriate links are followed by the URL in plain text. I'd suggest making certain the following is in your print stylesheet.

CSS

a:not([href^=javascript]):after {   content: " <" attr(href) "> "; } a[href="#"]:after {   content: "" !important; }

I'm going to go a little further here, because if you wish to exclude other links, let's say anything linked to "foo.com", for example, simply add those to the first rule, and use the in-string regular expression operator, like so...

CSS

a:not([href*=foo\.com]):not([href^=javascript]):after {   content: " <" attr(href) "> "; } a[href="#"]:after {   content: "" !imporant; }

...and you've included the link, enclosed in < and >, in your printed versions.

You'll notice, that on line one there are two differences in the attribute selector. First, I'm using a different regular expression selector, *= and second, I have a \ before the "." in "foo.com".

The selector *= matches a partial value in an attribute (you can learn more about regular expressions in attribute selectors at https://developer.mozilla.org/en-US/docs/Web/CSS/Attribute_selectors), so take care that you have the most complete partial possible - in my example, links to barfoo.com would also be excluded.

Additionally, the . is a special character in CSS syntax (as are ":" and "/"), which means it will need to be escaped in order to be seen as part of the value, just as "http://www.foo.com" would need to be escaped as "http\:\/\/www\.foo\.com".

That's all there is to it - powerful selectors and the function that returns an attribute can make your printed (and saved-to-PDF) documents better for your users.

Happy coding.

A Simpler Slider Toggle

A few years ago I wrote an article about what I called a "slider toggle". Because it was written so long ago, and user-agents change pretty frequently, I wanted to revisit it to see if I could make it easier. In the original post, I gave two different orientations - one horizontal and the other vertical - but both using a single "round button" style. I won't be doing that in this post. In this post all versions are horizontally oriented; however, there are two styles - one a round button and one a rectangular version (with rounded corners).

Again, in HTML terms, these are stylized checkboxes, and the overall approach has not changed. The primary changes are in the CSS used to generate the different looks. I've also included, in this post, an approach that has the button labels inside the button as part of the background. To make this post as easy to understand as possible, I've grouped the markup, images of rendered code, and a demo together, and placed the CSS at the end. The CSS handles all the different styles - both round button (which is the default style) and rectangular button and with external labels, internal labels, and no labels.

☝ Note that the label tag wraps the entire element. This is to increase the size of the target and make the toggle button behave in keeping with the skeuomorphic design. To compensate for the fragmentation possible on some platforms (with regard to accessibility), the label tags have been given a role of text.

It's also important to note that the code provided uses an HTML checkbox rather than a different element and the checkbox or switch role. The ARIA checkbox and switch roles are widget roles, which will likely be treated differently than native HTML. It is likely an interface using a widget role will be less discoverable than a native element with no ARIA role specified.

External labels

This example uses labels outside the switch and is the pattern used in my original post. As mentioned in the earlier post, because the non-visual interface is a checkbox, the visual-only labels whose meaning is only proximity-based are hidden from accessibility devices.

HTML

<label for="push-mode" role="text">   Push Notifications   <span class="switch-label" aria-hidden="true">Off</span>   <span class="switch">     <input id="push-mode" type="checkbox" value="on">     <span></span>   </span>   <span class="switch-label" aria-hidden="true">On</span> </label> <label for="airplane-mode" role="text">   Airplane Mode   <span class="switch-label" aria-hidden="true">Off</span>   <span class="switch slider">     <input id="airplane-mode" type="checkbox" value="on">     <span></span>   </span>   <span class="switch-label" aria-hidden="true">On</span> </label>

Internal labels

This example uses labels inside the switch. It is not recommended due to the variance in text length.

HTML

<label for="location-mode" role="text">   Location Services   <span class="switch">     <span class="switch-label" aria-hidden="true">on</span>     <input id="location-mode" type="checkbox" value="on">     <span class="switch-label" aria-hidden="true">off</span>     <span></span>   </span> </label> <label for="email-mode" role="text">   Electronic communication   <span class="switch slider">     <span class="switch-label" aria-hidden="true">ON</span>     <input id="email-mode" type="checkbox" value="on">     <span class="switch-label" aria-hidden="true">OFF</span>     <span class="slider"></span>   </span> </label>

Longer text length makes buttons appear less like buttons as can be seen in the 'other alerts' and 'bluetooth' examples.

HTML

<label for="alert-mode" role="text">          Other Alerts   <span class="switch">     <span class="switch-label" aria-hidden="true">apagado</span>     <input id="alert-mode" type="checkbox" value="on">     <span class="switch-label" aria-hidden="true">encendido</span>     <span></span>   </span> </label> <label for="bluetooth-mode" role="text">   Bluetooth   <span class="switch slider">     <span class="switch-label" aria-hidden="true">apagado</span>     <input id="bluetooth-mode" type="checkbox" value="on">     <span class="switch-label" aria-hidden="true">encendido</span>     <span class="slider"></span>   </span> </label>

Unlabeled

This example does not use interior or exterior labels. It is not recommended due to the increase in cognitive load caused by the lack of those labels.

HTML

<label for="busy-mode" role="text">   Busy   <span class="switch">     <input id="busy-mode" type="checkbox" value="on">     <span></span>   </span> </label> <label for="dnd-mode" role="text">   Do Not Disturb   <span class="switch slider">     <input id="dnd-mode" type="checkbox" value="on">     <span></span>   </span> </label>

CSS

The CSS for these items is relatively simple. The rule for the label element is left out as it does not affect the switch.

CSS

.switch-label {   font-size: 0.5em; } .switch:before {   content: '';   display: inline-block; } .switch .switch-label {   display: table-cell;   padding: 0 0.5em;   text-align: center;   vertical-align: middle;   width: 50%; } .swtich .switch-label:after {   content: '';   display: block;   margin-top: 100%; } .switch {   background-color: rgb(255, 255, 255);   border: 1px solid rgb(0, 0, 0);   border-radius: 0.7rem 0.7rem 0.7rem 0.7rem;   box-shadow: 0 0 0.1rem 0.1rem rgb(187, 187, 187) inset;   cursor: pointer;   display: inline-table;   min-height: 1.2em;   min-width: 2.3em;   position: relative; } .switch * {   -webkit-touch-callout: none;   -webkit-user-select: none;   -moz-user-select: none;   -ms-user-select: none;   user-select: none; } .switch input[type="checkbox"] {   position: absolute;   z-index: -1; } .switch > span:last-of-type, .switch.slider > span:last-of-type {   background-image: linear-gradient(to bottom, rgb(255, 255, 255) 0%, rgb(153, 153, 153) 100%);   border: 1px solid rgb(0, 0, 0);   border-radius: 0.7rem 0.7rem 0.7rem 0.7rem;   display: table-cell; /*inline-block*/;   min-height: 90%;   position: absolute;   top: 0;   width: 50%;   z-index: 2; } .switch > input[type="checkbox"]:not(:checked) ~ span:last-of-type {   left: 0; } .switch > input[type="checkbox"]:checked ~ span:last-of-type {   right: 0; } .switch > input[type="checkbox"]:focus ~ span:last-of-type {   border: 1px solid rgba(204, 204, 204, 0.8);   box-shadow: 0 0 5px rgb(102, 102, 102); } .switch.slider {   border-radius: 0.2rem;   box-shadow: 0 0 0.1rem 0.1rem rgb(187, 187, 187) inset; } .switch.slider > span:last-of-type {   background-image: linear-gradient(to bottom, rgb(255, 255, 255) 0%, rgb(153, 153, 153) 100%);   border: 1px solid rgb(0, 0, 0);   border-radius: 0.2rem; } .switch.slider > input[type="checkbox"]:focus ~ span:last-of-type, .switch.slider:hover > span:last-of-type {   border: 1px solid rgba(204, 204, 204, 0.8);   box-shadow: 0 0 5px rgb(102, 102, 102); }

Although this may require a few tweaks, such as changing the colors to match your design, this should be ready for you to test in your page.

Happy coding

You've Got Mail: Easy, accessible notifications

Today it's just a quick post to talk about how to do those notifications we've come to know – and since they are relatively simple, this will be short and to the point. An image is provided to show a basic example of what I'm describing.

First, let's start with the markup.

Since you'll likely have a list of possible notifications – for example, alerts or messages – put them in an unordered list. Each list item will contain a count of items and a type of items as well as a link to the item viewer. This will give you markup something like the example below. Note that this markup is fully accessible as is; however, the accessibility may be improved by adding a label to the unordered list identifying it as a list of notifications.

HTML

<ul class="notifications">   <li role="status">     <a href="/alerts.htm">       <span class="count">4</span>       <span class="type">Alerts</span>     </a>   </li>   <li role="status">     <a href="/messages.htm">       <span class="count">100</span>       <span class="type">Messages</span>     </a>   </li> </ul>

If the notifications are a live region – if they're automatically updated while the page is displayed in the browser – be sure to add the role attribute and set it to status so that changes are announced when the content is updated. To show how that would work, the role attribute is included in the example. It is important to note that the markup be readable as is, regardless of where the message parts, i.e., the count and type, are displayed.

Next, you'll add the style rules.

CSS

ul.notifications { nbsp;nbsp;margin:0;   padding:0;   text-align:right;   font-family:Verdana; } ul.notifications > li {   display:inline-block;   overflow:auto;   margin-right:1em; } ul.notifications > li:last-of-type {   margin-right:0; } ul.notifications > li > a > span.count, ul.notifications > li > a > span.type {   display:block;   position:relative; } ul.notifications > li > a > span.count {   background-color:rgb(255, 255, 255);   border:1px solid rgb(0, 0, 0);   border-radius:2em;   float:right;   font-size:0.5em;   text-align:center;   line-height:2em;   padding:0.2em;   width:2em;   z-index:1; } ul.notifications > li > a > span.type {   float:left;   line-height:3em;   z-index:0; }

Here, you'll want to pay special attention to setting the overflow to auto on the list item (this will make the list item contain the floating items), and setting the border-radius to the same value as the line-height on the span with class count – 2em in the example. Setting the height, width, and border-radius all to the same value will give the circle effect. Using a value of 2em for height and width with a font-size of 0.5em will allow you to easily display 3 digits within the circle. Also, be sure to set the z-index on the count to 1 in order to force it to display over the type. It is especially important to set the z-index when the background is set, otherwise the overlap will likely not work as you intend.

You'll notice that in our example, the count span is floating to the right and the type span is floating to the left. This floating pattern makes the count float over the lowercase portion of the type, meaning less content is hidden when there is overlap. You may just as easily float the count span left and leave all remaining code the same in order to have the number displayed on the left side of the type text.

Once you've set the HTML and CSS, you're ready to add any JavaScript you wish, for example, to make the notification viewer display as a modal window or automatically refresh the number of items in the count element.

That's it - you have all the code you'll need to make easy, accessible notifications, so...

Happy coding.

Scrolling, Scrolling

When you're short on real estate on your web page, one of the easiest things to do is shorten the height of an element and make it scrollable. This works especially well with a table, but if you're not careful, the header of the table will scroll along with all the content, making the column headers invisible and rendering the table more difficult to use. Fortunately, fixing this problem is relatively easy - as you'll see below.

First, you really should start with good, clean, semantic markup. That means a THEAD tag and a TBODY tag. So we'll start with something like the following...

HTML

<table class="scrollable">   <caption>10 of the world's busiest airports</caption>   <thead class="thead">     <tr>       <th>Country</th><th>City</th><th>Activity</th><th>Name</th><th>Latitude</th><th>Longitude</th>     </tr>   </thead>   <tbody>     <tr><td>US</td><td>ATL</td><td>68343</td><td>Hartsfield Jackson Atlanta International</td><td>33.636719</td><td>-84.428067</td></tr>     <tr><td>US</td><td>ORD</td><td>59692</td><td>Chicago O'Hare International</td><td>41.978603</td><td>-87.904842</td></tr>     <tr><td>US</td><td>DFW</td><td>56496</td><td>Dallas Fort Worth International</td><td>32.896828</td><td>-97.037997</td></tr>     <tr><td>US</td><td>LAX</td><td>51396</td><td>Los Angeles International</td><td>33.942536</td><td>-118.408075</td></tr>     <tr><td>CN</td><td>PEK</td><td>48226</td><td>Capital International</td><td>40.080111</td><td>116.584556</td></tr>     <tr><td>US</td><td>CLT</td><td>44583</td><td>Charlotte Douglas International</td><td>35.214</td><td>-80.943139</td></tr>     <tr><td>US</td><td>DEN</td><td>44438</td><td>Denver International</td><td>39.861656</td><td>-104.673178</td></tr>     <tr><td>US</td><td>LAS</td><td>41164</td><td>McCarran International</td><td>36.080056</td><td>-115.15225</td></tr>     <tr><td>US</td><td>IAH</td><td>39808</td><td>George Bush Intercontinental</td><td>29.984433</td><td>-95.341442</td></tr>     <tr><td>GB</td><td>LHR</td><td>37680</td><td>London Heathrow</td><td>51.4775</td><td>-0.461389</td></tr>   </tbody> </table>

Next, we need to adjust the CSS to override the default styles.

First, make sure that you have at least some specificity, otherwise all your tables, even those that take up very little vertical space will be affected. You'll notice from line 1 of our HTML that we're doing this by adding scrollable as a class on the table.

Second, we're adjusting both the TBODY and the TR tags to override the default. We're going to add a rule for overflow (on the y-axis) on the TBODY and for the height. A note about the height - the default line-height for a table row is 1.5 em, so if you don't adjust the line-height, using a multiple of 1.5 will give you a full line at the bottom - assuming you don't have borders around the TR or TD. In the example, I'm using a 6em height, which shows 4 full lines.

One might think that setting the height and overflow-y on the TBODY is enough, but alas it is not. The display mode is still table, which overrides the height specification. To correct this, I'll change the display to block. Unfortunately, that has the sad side-effect of rendering the cells within the table using an auto width. I'll correct this - in part by setting the display on the TR to table - and in part by setting the width on each of the columns. This gives us the CSS below.

CSS

table.scrollable > tbody {   display:block;   height:6em;   overflow-y:scroll; } table.scrollable > thead, table.scrollable > tbody tr {   display:table; } table.scrollable th:nth-child(1), table.scrollable td:nth-child(1) {   width:5.5em; } table.scrollable th:nth-child(2), table.scrollable td:nth-child(2) {   width:4em; } table.scrollable th:nth-child(3), table.scrollable td:nth-child(3) {   width:5.5em; } table.scrollable th:nth-child(4), table.scrollable td:nth-child(4) {   width:17em; } table.scrollable th:nth-child(5), table.scrollable td:nth-child(5) {   width:5.5em; } table.scrollable th:nth-child(6), table.scrollable td:nth-child(6) {   width:6.5em; }

If you would rather have evenly-spaced columns, you can set the width on the TR within the TBODY to 100% and change the table-layout to fixed, e.g., change line 8 in the CSS to display:table; table-layout:fixed; width:100%; and remove lines setting width on all columns.

That's it. Your table is now scrollable with a stationary header.

10 of the world's busiest airports

Country	City	Activity	Name	Latitude	Longitude
US	ATL	68343	Hartsfield Jackson Atlanta International	33.636719	-84.428067
US	ORD	59692	Chicago O'Hare International	41.978603	-87.904842
US	DFW	56496	Dallas Fort Worth International	32.896828	-97.037997
US	LAX	51396	Los Angeles International	33.942536	-118.408075
CN	PEK	48226	Capital International	40.080111	116.584556
US	CLT	44583	Charlotte Douglas International	35.214	-80.943139
US	DEN	44438	Denver International	39.861656	-104.673178
US	LAS	41164	McCarran International	36.080056	-115.15225
US	IAH	39808	George Bush Intercontinental	29.984433	-95.341442
GB	LHR	37680	London Heathrow	51.4775	-0.461389

Happy coding.

Testing? We don't need no stinkin' testing!

Today's post is twofold. Let me start with a story.

I was filling out an application online for a service, and the provider wanted my address. Although I'm unclear as to why it was required, it seemed reasonable enough. I was given a simple form with space for a street address, extended address, locality, region, and postal code - all easy enough. As I filled in the street address, the address verification started. As I continued typing, the address verification service displayed matching addresses in a drop-down list directly below the street address. When my address appeared in the list, I clicked it...and a message displayed that the address could not be retrieved. "OK", I thought, "I'll just add the locality, region, and postal code on my own"...but those fields had been disabled by JavaScript.

First, let me offer a few observations about the interface. To begin, I'm giving a +5 bonus on the Craft: Webpage check to the engineers who built the form because they tried to use Progressive Enhancement. If they hadn't, I would likely have been hopelessly stuck. As it was, I was able to turn off JavaScript (I highly recommend the Toggle JavaScript plugin for Chrome, by the way) and complete the form. Next, I'm given a -10 bonus on the Craft: Webpage check for requiring JavaScript to submit the form. Seriously?! Just make the submit button a submit button.

Also, I get why they wanted to turn off the Chrome address autofill - if there's a bad address in the cache it will get propagated to their system of record - but that assumes the person using the computer is less trustworthy than the system validating the address, and that's not always a good thing. Yes, users make mistakes, but that's why we do things like label our inputs and use skeumorphic (or otherwise familiar) design patterns. I would even go so far as to say that if your users are making a lot of "mistakes", like pulling on door handles when they should be pushing, your design needs to change...and there are a lot of examples of everyday things that are poorly designed, just take a look at some of the examples at baddesign.com, so you're not alone.

Addresses, however, are a special challenge. Why? Well, first because if you're doing anything internationally there are several different formats for addresses (luckily for you, http://prototypes.cathmhaol.com/hcard/ has most of them identified by the areas that use them) - there is a significant degree of ambiguity to address. Second, there has been a validation issue for a long time, which is why so many services have popped up to validate both foreign and domestic addresses. This is especially critical for online properties, because delivery is an issue that someone coming into a brick and mortar store does not face. In short, the technical and functional skills required to build a well-performing address component are not insignificant.

As I said earlier, this post is twofold. First, there are issues surrounding the address entry experience in my story. Yes, many of them were eased by the use of Progressive Enhancement - and that is a very important lesson here, because - and here's the second part - stuff breaks. We even have a saying that "complex systems break in complex ways"...and I can tell you based on my experience in the tech industry that it's not a matter of "if" but "when" and it will most likely be at the worst possible time. It will be in the last step of a multi-part process that makes customers so angry that not only will they not return, they'll tell 10 other people about their bad experience and soon you'll have a crowd of people who "know a guy".

So, let's look at what it would have taken to improve this experience - it's actually a pretty minor improvement. You'll notice from the story that there were two responses from the service. One was a response that included a matching address (that I clicked) and one was a response that the address could not be retrieved. Using simple logic we know that the user identified a verified address (so we don't really have to worry about a 'wrong' address) and that there was some sort of error during retrieval. Had the failure (error) case on the retrieval action enabled the fields that were disabled earlier, my work around would not have been necessary.

In order to have the best user experience you're going to want things like validation, autofills, animation, bells, whistles, and even the machine that goes "ping"...but all that complexity comes at a price...and that price is enhanced fault tolerance, error handling, and recovery...and testing...lots and lots of testing. All of that especially comes into play in data validation. In this specific case the engineers didn't need to worry so much about fault tolerance (we know the address is valid), but the error handling could use work. In cases where the fault tolerance or error handling is incomplete, or the testing of those two features is incomplete, you're often better off not having the functionality. Never assume something won't happen, because it will...and because assumptions are not a good thing (Robert's Rule #12). Consider this - "corner cases" and "outliers" exist often enough that we've named them...and if they've earned a name, they've earned our attention.

Now, go give the engineer who tests your code some pizza...or a donut...or a beer - something that says you appreciate them and how often they've saved you by identifying a corner case you missed.

Happy coding.

A Question of Semantics

Over the past (nearly) 20 years, one of the webhead topics for which I have been an advocate is the creation of semantic code. In the beginning, it was "semantic markup" because markup was really all we had. A little while later we added stylesheets and several of us also began thinking in terms of semantic styles. Now we're seeing other features, such as animation, carry meaning and are beginning to think of them in "semantic" terms as well1. Each of these has been layered upon the other - a figurative Aztec pyramid. semantic and what does it mean to write semantically and why worry about whether or not our markup, or CSS, or any other level of code is semantic?

First, let's address what we mean by writing "semantic code".

Let's begin by saying that not all code is semantic. We spend significant time considering the content of a web site, a page, or an application and how it carries meaning, but the code that wraps the content can either carrying meaning or not. When I wrap content in a DIV or P tag, I know something more about the content than content that is simply terminated with a line break (BR tag). If I use HTML5 and wrap content in an ASIDE tag or ARTICLE tag, I know even more about the content than if I had wrapped them in a DIV or P tag.

As another example, if I wrap a number in a SUP tag the only thing I know about that number is how it should be displayed; however, if I wrap a number in a SPAN tag with a semantic class attribute - footnote, for example - I now know something more about that number. Similarly, when I add WAI-ARIA2 attributes, such as aria-describedby even aria-hidden I am describing the content even more fully3 just as surely if I use an EM or STRONG tag instead of an I or B tag.

To put it simply, semantic code includes not only content, but meta-communication about that content.

So, why worry about whether or not our markup, or CSS, or any other code is semantic? The simple answer is that the meta-communication in code is as important, and in similar ways, as tone and body language are in verbal communication. The importance of meta-communicating code is easily seen when assistive technologies, such as screen readers like JAWS or VoiceOver, are used. Simply consider the difference between a I (italics) tag and an EM (emphasis) tag or a B (bold) tag and a STRONG (strong emphasis) tag. One category is visually oriented, but the other is both visually and verbally oriented, leading to a not only richer, but more precise, experience...one with less cognitive load...and the lower the cognitive load, the better the user experience (which anyone who is "customer-focused" wants).

At this point you might be thinking "I see the importance of semantic markup and using ARIA semantics, but why bother with the rest". Consider this - what do you think your experience would be like if face-to-face communication were missing an element of meta-communication. Would you gather as much meaning? Would it be as complete? As a society, we generally don't think so, which is why we have all sorts of assistive technology intended to help us compensate for missing elements - each element is significant. This significance should be carried over into the coding world. I would posit that we ought to go so far as to say that when any element of the code does not qualify as semantic that the code as a whole is not semantic.

At this point we have only discussed general benefits of semantic code in relation to humans. I haven't even touched on the benefits of semantic code in relation to machines. By using semantic CSS, for example, browser plugins are able to interface more fully with other applications - like calendars - especially when the CSS is a microformat. This opens the door to creation of a number of symbiotic relationships between your code and existing applications, especially in mobile channels where we have merely scratched the surface.

Beyond what we typically think of as code, however, we must also make sure other features - like animation - are semantic (seriously, if you haven't read Motion with Meaning: Semantic Animation in Interface Design yet, go do it) or, at the very least, don't break our semantic model, just as we ought make certain those features in the user interface do not increase cognitive load. One of the methods people who design user interfaces have used for decades that helps maintain a semantic approach and also tends to reduce cognitive load is skeuomorphism4. One of the most common historic examples of this method is making a data input form mimic the paper version; however, there are numerous other examples - folder and file images for directories on a computer or an image of a envelope for mail or email are just two examples.

In a previous post I wrote about a different (credit/debit) card input form I had developed5. Although that post discussed, in more general terms, creating a form that validates a credit/debit card including determining the brand, it links to an input form that uses a minimalist style - and there are reasons to use a minimalist, semantic approach at times - and contains the JavaScript to perform the validation. One of the deficiencies in that prototype, however, is the lack of semantic animation (in the minimizing of the account number input). That deficiency is addressed in another prototype where I take a skeuomorphic approach and create a card input form that looks and behaves much like its real-world counterpart. Feel free to take a look at both prototypes and see which is a more complete, user-friendly experience. I'm confident you'll find the more complete the semantic approach, the better the experience. (Of course, a combination of the two - the technical validation of version 1 and the skeuomorphic design of version 2 - is probably closer to ideal.)

All the issues I've brought to the fore so far are focused on the customer (user) experience, as they should be. However, there are other sides to the use of a semantic approach - SEO advantages and your (hopefully) friendly interface engineer, for example. Although the SEO benefits of the use of semantic markup and styles are becoming less dramatic than they were in the past, they are still present, and that will likely not change. A document a machine can read and understand will always fare better than one that is less understandable. As for interface engineers - semantic code makes understanding what is likely to be a complex solution a little easier. Reducing the cognitive load for an interface engineer generally means more productivity and less frustration. More productivity and less frustration will generally result in better code, so getting into the practice of writing semantic code can become a self-reinforcing loop and make the world a better place. Best of all, it means more happy coding.

Reference Notes (please note that links open in a new window).

1. Al Hazwani, Amin and Bernard, Tobias. Motion with Meaning: Semantic Animation in Interface Design. A List Apart. 19 January 2016. http://alistapart.com/article/motion-with-meaning-semantic-animation-in-interface-design (accessed 31 January 2016)
2. The WAI-ARIA specification divides the accessibility semantics into roles, states, and properties. You can see that specification at https://www.w3.org/TR/wai-aria/usage.
3. The WAI-ARIA semantics are very powerful, and getting their usage just right can be difficult, so if you're new to the whole "Accessible Rich Internet Applications" space, start with the W3C's ARIA Primer.
4. Skeuomorphism is the practice of making virtual items - such as data input forms - resemble their real-world counterpart. (https://www.techopedia.com/definition/28955/skeuomorphism)
5. King, Robert, 'A Better Credit Card', Getting Paid to Think [weblog]. 28 December 2012, http://gettingpaidtothink.blogspot.com/2013/02/a-better-credit-card.html.

A Simple CSS Transform

One of the more interesting things browsers are supporting now are 3D transformations - and using them you'll hit about 90% of your users. Are they incredibly useful...as useful as say calc or regex-style selectors? No. But I'm all about progressive enhancement, and reducing cognitive load and this can go a long way to that.

Since most of my experience is in working with the financial industry, I'm going to give you a real-world example of how you might use this nifty little feature, albeit simplified, while also explaining just how it can be done.

I'm going to construct a page that has a credit card entry form and also an image to explain show where to get the numbers. For this example, I'm only going to use two rather simplified images (shown here); however, the image of the card back will be flipped horizontally before being saved as a JPEG.

In a real-world use, I would likely use several images of the front, each highlighting a data point, e.g. account number, expiration date, and name, and tie each of those images to the focus pseudoclass for the appropriate field, but as this is only an example, I'm trying to simplify it here. Of course that also means that code listings are going to be somewhat incomplete.

HTML

<span class="help">?</span> ... <div class="card"></div>

CSS

.help {   background:#efefef;   border:1px solid #ddd;   border-radius:0.7em;   cursor:pointer;   display:inline-block;   font-weight:bold;   height:1.2em;   margin-right:2em;   text-align:center;   width:1.2em; } .help:hover + .card {   background-image:url("creditcardback.jpg");   -webkit-transform:rotateX(0deg) rotateY(180deg);   transform:rotateX(0deg) rotateY(180deg); } .card {   background:#fff url("creditcardfront.jpg") no-repeat center;   border-radius:5px;   border:1px solid #000;   clear:both;   float:none;   height:120px;   width:180px;   -webkit-transform:rotateX(0deg) rotateY(0deg);   transform:rotateX(0deg) rotateY(0deg);   -webkit-transform-style:preserve-3d;   transform-style:preserve-3d;   transition:transform 1s; }

Using the transform to rotate on the Y-axis (lines 15/16 and 27/28 in the CSS listing) flips the image on the horizontal axis in a one second animation (line 31 in the CSS listing). This in itself is not necessarily a useful trick, because the image is then backwards, but replacing the background image (line 14 in the CSS listing) while it's flipped gives the illusion that you're looking at the back of the same image.

Of course you can use a pseduoclass other than hover - focus comes to mind as one that may be useful. Also, your CSS may need to be more complex in order to get everything positioned just where you want...or you may need to tweak it in other ways, but this will give you the general idea of how to create a simple animation that's tied to a real-world implementation.

If you want to see how it works, or if it works in your browser, if you're using the 'desktop' site, just hover over the 'help' icon (?) in the example below and if you're using a mobile version, tap on the 'help' icon (?) in the example below. Moving the hover outside the help icon (or tapping outside the 'help' icon) will flip the card back over.

?

A Customized Checkbox

It's been a while since I've made a post, but it's always good to take a little time to recharge.

I was presented with an interesting problem recently. A colleague of mine needed to display a customized checkbox on a web page. As many of you undoubtedly know, however, customizing a checkbox in a browser is nearly impossible. Most of the time we're left with the rather ugly instead of something pretty when what we want is something like the examples shown in the image to the right.

If you search online for a solution, what you'll find - or at least what I found - is that typical solutions are either not semantic or are not accessible, or both. As anyone who knows me can attest, I'm not satisfied with something that is either not semantic or not accessible, so I started out to build something better.

What I ended up doing is starting with absolutely semantic markup - an INPUT tag and a LABEL tag, i.e., <INPUT id="cbx" name="cbx" type="checkbox" value="1" /> <LABEL for="cbx">Check</LABEL> and then added the CSS to style it. It's important to note that the markup always has the INPUT tag first and the LABEL tag immediately following it - even though in the example image Example 2 shows the checkbox after the label.

The CSS then, hides the input in an accessible manner using the clip property. Since the INPUT is hidden, but can still receive focus using the keyboard (an important accessibility feature), you need to show the user an indication that the field has received focus. By default, this is typically done using a one pixel dotted black border, so feel free to use that, but be sure to add a transparent border to the LABEL when the checkbox does not have focus, otherwise your user will see a flicker as the label shifts back and forth by one pixel.

Also, since the INPUT is clipped, you'll need something to show the user thé state of the checkbox. We're going to do this using a background image on the label. In my example, I've used a simple checkbox with a gradient from top left to bottom right for unchecked and a green checkmark when it's checked (using the psuedoclass 'checked'). If the input is to be displayed to the right, I accommodate that by adding a class 'right' to the INPUT element, which changes the background position to center right.

One design note - this was done very quickly and with minimal image editing, so you'll probably want to do things like make sure your 'checked' and 'unchecked' images have transparent pixels to the left and/or right so that you can add padding to the left and right on your label to make your focus border look a little better.

Although I don't do anything with the indeterminate state, you can add that if you'd like...although I'm not sure it makes sense in most experiences. To add an indeterminate state, you'd simply add an input[type="checkbox"]:indeterminate + label rule to your stylesheet with an associated background image. If you'd like more information about the psuedoclass, checkout out the MDN entry.

Aside from the indeterminate psuedoclass, all my rules can be seen in the style below or you can take a look at the prototype page to see what it looks like in your browser. In the coming days I will likely be fine tuning the prototype to make the design a little more attractive, but here's the brief version of this little snippet.

input[type="checkbox"] {
  clip:rect(0, 0, 0, 0);
  position:absolute;
}
input[type="checkbox"] + label {
  background-image:url("unchecked_ico.png");
  background-position:left center;
  background-repeat:no-repeat;
  border:1px solid transparent;
  font-size:15px;
  padding-left:20px;
}
input[type="checkbox"]:checked + label {
  background-image:url("icon_checkbox_1.gif");
}
input[type="checkbox"]:focus + label {
  border:1px dotted #999;
}
input[type="checkbox"].right + label {
  background-position:right center;
  padding-left:0;
  padding-right:20px;
}

Happy coding.

An Experiment in Design

While I was been between contracts, I was able to pursue a project that I've had in mind for a while, as well as spending some quality time with my child. After finishing the project - or at least this iteration of it - I thought I'd sit down and put a few thoughts together about it, because I any project or task can teach us something, if we're willing to look for the lesson and learn.

A little about the project

I have a 2002 Honda Rebel, and as much as I love the bike overall, there are a few design features that I just don't care for - a good example is the battery box cover and the matching air filter cover

You can see the chrome trimmed white plastic battery box cover on the bike in the picture to the to the right under the seat/fuel tank.

There's nothing terribly awful about the covers, they just stick out too far and are too plain for me - and I'd like a little more of the machine to show through. For the battery box cover, the solution was simple - remove the plastic cover and expose the battery and paint the black plastic liner white. That the metal frame that keeps the battery liner in place is black is a bonus, because I think makes a better contrast than chrome. For the air filter cover; however, the solution is a little more tricky, because the cover is not held in place with multiple screws, but by pins that extend out of the OEM air filter cover and rest in receivers on the white/chrome cover - but I was sure I wanted to change that as well.

What I did

After considering a number of options - among them fabricating a metal replacement or drafting and 3D printing a part - I settled on what I considered to be the most cost-effective and forgiving - polymer clay.

I started the process by creating a template using the existing air filter cover and then working the polymer clay into the correct shape. After the piece was the correct shape, I cured the clay according the manufacturer's instructions. Once the clay was cured, I took it to the bike and trimmed and filed it into the best fit possible. Once I knew it fit, I put ink on the receiving nuts inside the air filter compartment and pressed the plate onto the nuts and then made the holes in the correct position. To make sure I won't have to repeat many of the steps in this process, I used the completed part to make a permanent template that I also annotated with specific dimensions so I can more easily duplicate the process in the future - that's the image you see to the right (which in its original form is 8.5"x11" - you can get a PDF copy by contacting me).

Once the part was completed, I selected an image and began the process of transferring it to the part. I had originally tried transferring the image to the polymer clay the normal way using a transfer sheet; however, that did not work well (I assume because of the size of the image). Since that didn't work, I switched to the old-school method, masking off portions of the part and painting the unmasked portions. Because the image I chose is one that's typically political graffiti, I chose to skip the airbrush that would have given a "too polished" look and instead used a paintbrush. I also considered only masking the top, bottom, and inside borders and using a dry brush, but wanted the image to be really clear.

Again, I'm keeping costs on a near-zero level, so I'm using Testor™ brand enamel, which turned out better than I expected on the polymer clay, and was way better on the budget than a $20 can of orange paint that I'd use once to cover a few square centimeters and then wait for it to fall off the shelf and spray random items in the garage. I don't know about you, but I prefer to not have random items partially spray-painted orange - or green for that matter, even though green is a better color than orange.

At this point, I added the motto (Tiocfaidh ár Lá) under the graphic, but I was very dissatisfied with how it looked overall at that point. I didn't, however, let this one minor failure set me back - I simply repainted that section and moved on.

After the piece was painted and dry, the next thing I needed to address was the bolts used to install the cover. The OEM bolts fit the OEM cover - which is about 15mm from the top of the housing to the outside of the cover. Since my part is only about 10mm thick, the OEM bolts were about 5mm too long. A quick trip to the hardware store for M6 x 16 x 1.0 bolts and I was back to the project. A few sprays from the white Rustoleum™ on the bolts and washers, a little time to let them dry, and I was back in the garage bolting the part down with the now-white bolts.

Although the fuel tank and the cover are different shades of white, the difference is not nearly as noticeable in person as it is in the photo where the flash was pointed right at the newly-fabricated, freshly-painted part.

What did I learn and how does it apply elsewhere?

First, before I started this project, I only knew that I was dissatisfied with a couple of features on my bike - I had no idea what options there were. As I searched in vain for an aftermarket theme-based kit or even parts I could use to mod the bike, I began to get a little discouraged. There are standard accessories - floorboards, saddlebags, grips, windshields, and so forth - but nothing that would allow you to take a bike from boring, off-the-showroom-floor standard to an interesting, showcase, theme bike in a weekend (or two) of work. Without the encouragement an easy solution offers, we often settle for mass-market produced, mildly interesting designs, when we can have more. We need to recognize more often that making our mark is usually easier than we think it is and is always worth the attempt, even if we fail. I still think it would be cool if there were aftermarket theme-based kits...maybe when I win the lottery and can pursue all my hobbies with abandon, there will be and we can all express ourselves a little easier.

Second, I mentioned that I was able to spend some quality time with my child - that was because she was right beside me during much of this little project. I did not allow her to handle the paint, but she was able to hand me tools while I took off the OEM covers and help keep track of the handful of little bolts, she also helped condition the clay and helped with the first fitting, and eagerly expressed her joy when seeing that what didn't really look like anything at the beginning (while I was cutting out the image for the center panel) was recognizable when it was complete. She didn't really have an idea of what the "big picture" was, she just trusted that her contribution was valuable and valued - which it was. It's worth noting that the small encouragement in her joy meant mountains to me - it's easier to face challenges or the threat of failure when your teammates are so encouraging. In a lot of ways, as engineers we're unlike my daughter, but we need to be more like her. Sometimes we see only bits and pieces of a project, but that does not mean we should think one contribution or another is less valuable; all contributions are valuable and deserve recognition - even if the contribution is that we're "just part of the team". We don't always see how things fit together until they do, but making judgments about which are the most valuable pieces before we understand the puzzle invites assumption.

Finally, as I told my wife, this was something of an experiment. I wondered if I could easily, inexpensively modify my bike in a way that I liked. I had a few things going against me - I'd never modified a vehicle before, I'd never fabricated a part before, I have no CAD skills, I don't have a workshop full of tools, I don't...I'd never...all the negativity was nearly overwhelming. I did it anyway. Overall, I consider the experiment successful. I spent less than $15, took less than 5 hours all together (though it was broken up into 5-year-old attention span sized pieces), and was more than mildly pleased with the result. Along the way, I learned a few things - I know I'm very likely to change the design at some point, and I very likely to even change my approach - but by being willing to set aside the negativity while still realizing that I may fail, and realizing that "failing" would be OK because I would have learned how not to do something, I made things better - I like the new look better and I like the new feel of the bike too, made it my own, and it's now like no other.

Get out there. Try something different. Make your mark. Above all, ride safe.