Curt Long

In today’s digital landscape, developers constantly need to be adding new tools to remain competitive and at the top of their craft. If you regularly create new web or mobile applications, then Amazon Cognito is a powerful tool that can cut 90% of the time it usually takes to set up a custom user-management solution. If that is intriguing to you, then let’s continue the journey to learn more about what Amazon Cognito has to offer.

In Our Last Episode

In the previous article, I introduced the concept of user management and how complicated it is in our current digital landscape. In addition, I introduced Amazon Cognito (henceforth referred to as Cognito), a service provided through Amazon Web Services, as a way to deal with this complexity. To illustrate this, I created an iOS application that uses Cognito to provide a login for users using a custom user pool.

Now that we have the basics of an application in place, I want to implement several aspects of user management within the sample application. These aspects include user signup, email verification, password resetting and multi-factor authentication. After that, I want to talk through some of the additional value that Cognito provides through its security model and how you could use it to secure the back end of your application.

To get up and running for this article, you’ll need to leverage the user pool that was created in the previous article. If you haven’t done that work, you can be up and running in about 30 minutes and ready to move forward with what I am covering today.

Sample Code

If you are following along with the sample code, you will need to have set up a user pool, configured it properly, and added the settings to a plist file before the application will work. This is a fairly simple (but lengthy) process that was covered thoroughly in the previous article. Most every section of this article will include a link to the Git tag that is used at that point of the code. I hope this will make it easier to follow along.

Letting Users Sign Up

The first step in a user’s journey in your application is the signup process. Cognito provides the capability to allow for users to sign up or to allow only administrators to sign up users. In the previous article, we configured the user pool to allow users to sign up.

One key element to remember in regards to signup is that this is where your attribute settings and password policy are enforced. If you set attributes as required in the user pool, you will have to submit all of those values in order for your signup call to be successful. In our case, we need to gather the user’s first name, last name, email address and desired password.

In this new view controller, SignupViewController, we have an action that gets called when the user clicks the “Complete Registration” button. We need to respond to a few things if they occur:

• If there is an error, we need to present the error to the end user and allow them to resubmit the form.
• If we are successful with the signup, we need to check whether the user requires verification of their email address. According to how we set up the user pool, this is a requirement. In most all cases, the user will be required to go to the next step and verify their email address.

The following code represents this process in action:

@IBAction func signupPressed(_ sender: AnyObject) { // Get a reference to the user pool let userPool = AppDelegate.defaultUserPool() // Collect all of the attributes that should be included in the signup call let emailAttribute = AWSCognitoIdentityUserAttributeType(name: "email", value: email.text!) let firstNameAttribute = AWSCognitoIdentityUserAttributeType(name: "given_name", value: firstName.text!) let lastNameAttribute = AWSCognitoIdentityUserAttributeType(name: "family_name", value: lastName.text!) // Actually make the signup call passing in those attributes userPool.signUp(UUID().uuidString, password: password.text!, userAttributes: [emailAttribute, firstNameAttribute, lastNameAttribute], validationData: nil) .continueWith { (response) -> Any? in if response.error != nil { // Error in the signup process let alert = UIAlertController(title: "Error", message: response.error?.localizedDescription, preferredStyle: .alert) alert.addAction(UIAlertAction(title: "OK", style: .default, handler:nil)) self.present(alert, animated: true, completion: nil) } else { self.user = response.result!.user // Does user need verification? if (response.result?.userConfirmed != AWSCognitoIdentityUserStatus.Confirmed.rawValue) { // User needs confirmation, so we need to proceed to the verify view controller DispatchQueue.main.async { self.performSegue(withIdentifier: "VerifySegue", sender: self) } } else { // User signed up but does not need verification DispatchQueue.main.async { self.presentingViewController?.dismiss(animated: true, completion: nil) } } } return nil }}

Verifying Email Addresses

Email verification is configured in the creation of the user pool, which we covered in the previous article. As you can see in the following image, we chose to require email validation for users. By verifying email addresses, we can leverage the addresses for other use cases, such as resetting passwords.

Workflow

The entire signup process will also include verification if the user pool was configured that way. The “happy path” representation of this flow would be as follows:

1. The user is presented with the login screen when launching the application.
2. The user presses the “Sign up for an account” option on the login screen.
3. The user is presented with the signup form.
4. The user fills out the signup form correctly with their information.
5. The user is presented with the email verification form.
6. The user enters the code from their email.
7. The user is sent back to the login form, where they can now log in with their new account.

This flow can be seen in the following view controllers, which are a part of the sample application:

There is one important note about verification to consider. If you decide to require both email address and phone number for verification, Cognito will choose to insert the phone number verification into the signup process. You will then have to detect whether the email address is verified and include the logic required to verify it. However, in most cases, if you verify one of the attributes and use it for password resetting, then there isn’t as much of a need to verify the other. If you plan to use multi-factor authentication, I would recommend requiring phone-number verification only.

Coding the Email Verification

Two key actions need to be supported in the view controller that is handling the verification process: submitting the verification code, and requesting that the code be sent again. Luckily, these two actions are fairly easy to implement, and the code can be seen below:

func resetConfirmation(message:String? = "") { self.verificationField.text = "" let alert = UIAlertController(title: "Error", message: message, preferredStyle: .alert) alert.addAction(UIAlertAction(title: "Retry", style: .default, handler: nil)) self.present(alert, animated: true, completion:nil)}@IBAction func verifyPressed(_ sender: AnyObject) { // Confirm / verify the user based on the text in the verify field self.user?.confirmSignUp(verificationField.text!) .continueWith(block: { (response) -> Any? in if response.error != nil { // In this case, there was some error or the user didn't enter the right code. // We will just rely on the description that Cognito passes back to us. self.resetConfirmation(message: response.error!.localizedDescription) } else { DispatchQueue.main.async { // Return to Login View Controller - this should be handled a bit differently, but added in this manner for simplicity self.presentingViewController?.presentingViewController?.dismiss(animated: true, completion: nil) } } return nil })}@IBAction func resendConfirmationCodePressed(_ sender: AnyObject) { self.user?.resendConfirmationCode() .continueWith(block: { (response) -> Any? in let alert = UIAlertController(title: "Resent", message: "The confirmation code has been resent.", preferredStyle: .alert) alert.addAction(UIAlertAction(title: "OK", style: .default, handler: nil)) self.present(alert, animated: true, completion:nil) return nil })}

As discussed in the signup and verification flow section, if the user is successful in verifying their address, they will be sent back to the login screen. After this login, the user will be able to get into the protected view within the application, which will display their attributes.

Signup and verification were relatively painless. If you want to see the code at this point of the article, check out the signup-verify tag of the code on GitHub.

Forgot Password

Another key use case in user management is helping users to reset their password securely. Cognito provides this functionality through either email or text message, depending on how the user pool has been configured.

It is important to note that verification is required for resetting a user’s password. If you don’t specify either the phone number or email address to be verified, then the user will have to reach out to you to reset their password. In short, every user pool should have, at minimum, one verified attribute.

Workflow

Just as with signup and verification, the forgot-password workflow is a multi-step process. To achieve the goal of resetting the user’s password, we need to follow these steps (which only include the happy path):

1. We need to get the user’s email address to get a reference to the user.
2. We need to request that a verification code be sent to the user. If the user pool has a verified phone number, it will be sent as an SMS. If there isn’t a verified phone number, it will be sent as an email.
3. We need to inform the user where to look for the code in a secure manner. Cognito returns a masked version of the phone number or email address, to give the user a heads up of where to look.
4. We allow the user to fill out a form, including both the verification code and a new password.
5. We submit the password and verification code to Cognito.
6. We let the user know that their password reset was successful, and they can now log into the application.
7. We send them back to the login screen.

This flow can be seen in the following view controllers, which are a part of the sample application:

Coding the Forgot-Password Workflow

The first step in coding this workflow is to request that the user be sent a verification code. To do this, LoginViewController will pass the email address to ForgotPasswordViewController before the segue is performed. Once the new view appears, the email address will be used to get a reference to the user and request a verification code.

override func viewDidAppear(_ animated: Bool) { super.viewDidAppear(animated) if !emailAddress.isEmpty { // Get a reference to the user pool let pool = AppDelegate.defaultUserPool() // Get a reference to the user using the email address user = pool.getUser(emailAddress) // Initiate the forgot password process, which will send a verification code to the user user?.forgotPassword() .continueWith(block: { (response) -> Any? in if response.error != nil { // Cannot request password reset due to error (for example, the attempt limit is exceeded) let alert = UIAlertController(title: "Cannot Reset Password", message: (response.error! as NSError).userInfo["message"] as? String, preferredStyle: .alert) alert.addAction(UIAlertAction(title: "OK", style: .default, handler: { (action) in self.clearFields() self.presentingViewController?.dismiss(animated: true, completion: nil) })) self.present(alert, animated: true, completion: nil) return nil } // Password reset was requested and message sent. Let the user know where to look for code. let result = response.result let isEmail = (result?.codeDeliveryDetails?.deliveryMedium == AWSCognitoIdentityProviderDeliveryMediumType.email) let destination:String = result!.codeDeliveryDetails!.destination! let medium = isEmail ? "an email" : "a text message" let alert = UIAlertController(title: "Verification Sent", message: "You should receive (medium) with a verification code at (destination). Enter that code here along with a new password.", preferredStyle: .alert) alert.addAction(UIAlertAction(title: "OK", style: .default, handler: nil)) self.present(alert, animated: true, completion: nil) return nil }) }}

One point to note on this is that Cognito returns information that enables you to tell the user where to find the code. In the code above, we are detecting whether the code will be sent to an email address or phone number, as well as the masked version of the destination. This can be seen in the sample application in the image below.

After requesting the code, we need to allow the user to enter the new code and updated password. This code from ForgotPasswordViewController is triggered when the user clicks on the “Reset Password” button.

@IBAction func resetPasswordPressed(_ sender: AnyObject) { // Kick off the 'reset password' process by passing the verification code and password user?.confirmForgotPassword(self.verificationCode.text!, password: self.newPassword.text!) .continueWith { (response) -> Any? in if response.error != nil { // The password could not be reset - let the user know let alert = UIAlertController(title: "Cannot Reset Password", message: (response.error! as NSError).userInfo["message"] as? String, preferredStyle: .alert) alert.addAction(UIAlertAction(title: "Resend Code", style: .default, handler: { (action) in self.user?.forgotPassword() .continueWith(block: { (result) -> Any? in print("Code Sent") return nil }) })) alert.addAction(UIAlertAction(title: "Cancel", style: .cancel, handler: { (action) in DispatchQueue.main.async { self.presentingViewController?.dismiss(animated: true, completion: nil) } })) self.present(alert, animated: true, completion: nil) } else { // Password reset. Send the user back to the login and let them know they can log in with new password. DispatchQueue.main.async { let presentingController = self.presentingViewController self.presentingViewController?.dismiss(animated: true, completion: { let alert = UIAlertController(title: "Password Reset", message: "Password reset. Please log into the account with your email and new password.", preferredStyle: .alert) alert.addAction(UIAlertAction(title: "OK", style: .default, handler: nil)) presentingController?.present(alert, animated: true, completion: nil) self.clearFields() } ) } } return nil }}

Once this process is complete, the user is returned to the login screen and informed that the password reset was successful. At this point, the user can log into the application using their new password.

If you want to see the code at this point of the article, check out the forgot-password tag of the code on GitHub.

Multi-Factor Authentication

Multi-factor authentication (MFA) is becoming a standard for anything requiring heightened security. Right now, if I want to log into my email, my bank, my mortgage account or even GitHub, I have to enter a code that I get via text message. Because of this extra layer of security, we prevent anyone from logging into an account if they have both my username and password. Instead of just using a single factor (the password) with the username, they have to use multiple factors (password and the code via SMS).

The great thing is that Cognito supports this out of the box through SMS. The Cognito team has stated that it is also working to add support for email MFA; however, at the time of writing, this isn’t an option. To make this work, we’ll need to change some configuration settings in AWS and create a new user pool.

New User Pool

To properly demonstrate the capabilities of multi-factor authentication using SMS, I will be creating a new custom user pool with only a few modifications compared to our previous user pool. Note that some features (such as required attributes) cannot be modified once a user pool has been created. Because of this, you’ll want to have a solid strategy around your user pool before starting to use it.

The modifications that I made compared to the previous user pool are detailed below:

• Phone number has been added as a required attribute.
• Users can sign in using their email address or phone number (we will still choose the email address here).
• Multi-factor authentication has been set as optional.
• Email verification has been disabled, and phone number verification has been enabled.

Using SMS Instead of Email

If you are going to send anything more than a few SMS messages per month, you’ll need to request a higher Simple Notification Service (SNS) limit for SMS messages. This is mostly painless, but it is a requirement if you are going to ship an app. The following excerpt from Cognito’s documentation will point you in the right direction. While the team responds to requests fairly quickly, it isn’t instant. I would recommend submitting the request at least a few weeks before a push to production. According to “Specifying User Pool MFA Setting and Email and Phone Verification Settings” in the Amazon Cognito Documentation:

The default spend limit per account (if not specified) is 1.00 USD per month. If you want to raise the limit, submit an SNS Limit Increase case in the AWS Support Center. For New limit value, enter your desired monthly spend limit. In the Use Case Description field, explain that you are requesting an SMS monthly spend limit increase.

Workflow

Because we aren’t forcing multi-factor authentication for the user pool (although you certainly could), we will have a multi-step process to enable and then execute multi-factor authentication. These steps are detailed below (these are the happy path steps):

1. When the user signs up for an account, they will be asked to verify their phone number (instead of their email address).
2. After logging into the application, the user will be able to enable multi-factor authentication in their profile.
3. After enabling multi-factor authentication, the user will be presented with the authentication challenge upon their next login.
4. Upon entering the multi-factor authentication code correctly, the user will be able to use the application as expected.

Coding Multi-Factor Authentication

The Cognito SDK triggers the display of the multi-factor authentication view controller. You have to define how you want to handle that trigger. In the sample application, this happens in AppDelegate. Because our AppDelegate implements AWSCognitoIdentityInteractiveAuthenticationDelegate, we have the option to define how we want this to be handled. The code below shows the implementation in the sample application:

func startMultiFactorAuthentication() -> AWSCognitoIdentityMultiFactorAuthentication { if (self.multiFactorAuthenticationController == nil) { self.multiFactorAuthenticationController = self.storyboard?.instantiateViewController(withIdentifier: "MultiFactorAuthenticationController") as? MultiFactorAuthenticationController } DispatchQueue.main.async { if(self.multiFactorAuthenticationController!.isViewLoaded || self.multiFactorAuthenticationController!.view.window == nil) { self.navigationController?.present(self.multiFactorAuthenticationController!, animated: true, completion: nil) } } return self.multiFactorAuthenticationController!}

In the case above, we instantiate the view controller from the storyboard, and then we present it. Finally, this view controller is presented.

Within MultiFactorAuthenticationController, we handle the process much like we did in LoginViewController. The view controller itself implements a protocol that is specific to this use case: AWSCognitoIdentityMultiFactorAuthentication. By implementing this protocol, you get an instance in the getCode method, which you must use to pass in the code for verification. The result of this verification will trigger the didCompleteMultifactorAuthenticationStepWithError method.

class MultiFactorAuthenticationController: UIViewController { @IBOutlet weak var authenticationCode: UITextField! @IBOutlet weak var submitCodeButton: UIButton! var mfaCompletionSource:AWSTaskCompletionSource? @IBAction func submitCodePressed(_ sender: AnyObject) { self.mfaCompletionSource?.set(result: NSString(string: authenticationCode.text!)) }}extension MultiFactorAuthenticationController: AWSCognitoIdentityMultiFactorAuthentication { func getCode(_ authenticationInput: AWSCognitoIdentityMultifactorAuthenticationInput, mfaCodeCompletionSource: AWSTaskCompletionSource) { self.mfaCompletionSource = mfaCodeCompletionSource } func didCompleteMultifactorAuthenticationStepWithError(_ error: Error?) { DispatchQueue.main.async { self.authenticationCode.text = "" } if error != nil { let alertController = UIAlertController(title: "Cannot Verify Code", message: (error! as NSError).userInfo["message"] as? String, preferredStyle: .alert) let resendAction = UIAlertAction(title: "Try Again", style: .default, handler:nil) alertController.addAction(resendAction) let logoutAction = UIAlertAction(title: "Logout", style: .cancel, handler: { (action) in AppDelegate.defaultUserPool().currentUser()?.signOut() self.dismiss(animated: true, completion: { self.authenticationCode.text = nil }) }) alertController.addAction(logoutAction) self.present(alertController, animated: true, completion: nil) } else { self.dismiss(animated: true, completion: nil) } }}

One additional piece needs to be noted. Because we didn’t force every user to use multi-factor authentication, we have to give the user the option to enable it. To do this, we’ll need to update the user’s settings. The code below (from AppViewController) demonstrates how to both enable and disable multi-factor authentication by using UISwitch as input:

let settings = AWSCognitoIdentityUserSettings()if mfaSwitch.isOn { // Enable MFA let mfaOptions = AWSCognitoIdentityUserMFAOption() mfaOptions.attributeName = "phone_number" mfaOptions.deliveryMedium = .sms settings.mfaOptions = [mfaOptions]} else { // Disable MFA settings.mfaOptions = []}user?.setUserSettings(settings).continueOnSuccessWith(block: { (response) -> Any? in if response.error != nil { let alert = UIAlertController(title: "Error", message: (response.error! as NSError).userInfo["message"] as? String, preferredStyle: .alert) alert.addAction(UIAlertAction(title: "OK", style: .default, handler: nil)) self.present(alert, animated: true, completion:nil) self.resetAttributeValues() } else { self.fetchUserAttributes() } return nil})

To see the code at this point of the article, check out the mfa tag of the code on GitHub.

Taking It Further: API Security

One of the benefits of using Cognito for user management is how it integrates with other AWS services. One great example of this is how it integrates with API Gateway. If you want to have a set of APIs that only logged-in users can access, you can use the user group authorizer for API Gateway. This allows you to pass the token you receive when logging into your API calls, and API Gateway will handle the authorization for you.

This can be particularly powerful if you want to set up a serverless back end (via Lambda) that is exposed through API Gateway. This means you could pretty quickly set up a secured set of API endpoints to power your web or mobile application. If you are interested in exploring this more, feel free to check the following article from the API Gateway documentation: “Use Amazon Cognito User Pools with API Gateway.”

Unfortunately, setting up a back end with Lambda is beyond the scope of this article. However, Amazon has provided a resource on getting started with Lambda: “Build an API to Expose a Lambda Function.”

Conclusion

Within a couple of articles, we have managed to progress from an insecure application to an application that supports all of the common user management use cases. What’s even better is that this user management capability is a service supported by AWS, and until you get over 10,000 active users, it is mostly free to use. I believe that whether you are a web, iOS or Android developer, this toolset will prove to be a valuable one. I’m sure you’ve got an idea of what you can build to test this out. Feel free to use the sample code to help you in that process.

Happy coding!

Links and Resources

• Amazon Cognito
• “Developer Resources,” Amazon Cognito
• “AWS Mobile SDK,” AWS

(This is a sponsored post). Color is one of the most powerful tools in a designer’s toolkit. Color can draw attention, set a mood, and influence the user’s emotion, perception and actions. When it comes to the web and mobile app design, this is definitely a time of vibrant colors. Designers use vibrant colors to focus people’s attention on important elements and to make their designs memorable.

In this article, I’ll summarize a few popular techniques of using vibrant colors in web and mobile design. Also, if you’d like to get started designing and prototyping your own web and mobile experiences, download Adobe XD.

Monotone

One of the most popular ways to use vibrant colors is with a monotone color palette. A monotone palette has a single color with a mixture of tints and tones. Such color palettes are visually stimulating. Paired with attention-grabbing typography, a monotone color scheme is able to create a really memorable experience.

Tip: Monotone is great for mobile apps. Using a single color with black and white accents is a great way to create visual interest on a small screen.

Duotone

As the name suggests, a duotone is made up of two colors. It could be two shades of the same color or two contrasting colors. This technique, once a print staple, has found new life online. Thanks to Spotify, duotones are growing in popularity every day.

Create Emotions

Duotones enable you to inject any image with the emotional attributes of any color. Different colors evoke different emotions:

• Soft and modest combinations of colors create a serious atmosphere. In Holm Marcher & Co, shown below, every detail contributes to the businesslike atmosphere, and the background image is no exception.
  

  

• A combination of bright colors creates a sense of happiness. The main visual for New Deal Design is striking, thanks to the bold color choice. It creates a friendly atmosphere and sets a positive mood.

Improve Readability

A duotone can give text plenty of contrast. The color variation in an image is adjusted so that text can be shown in a single color almost anywhere on the image.

Translates Well on Mobile

Last but not least, while the duotone effect lends itself to large desktop images, it can work on mobile screens as well.

Tip: If you want to use a duotone for a hero image, select a simple high-quality photo with a single, clear subject. A busy photograph with a lot of detail might be harder to interpret.

Gradient

Gradients have made their way back into modern user interfaces, this time as high-contrast complementary colors. Modern gradients can include multiple colors, can radiate from the center, and can come from a corner or fall horizontally.

They serve the following functions in user interfaces.

Create a Modern Look

Gradients have made a comeback and breathed new life into flat design. Paired with flat color palette, they can evoke a feeling of modernism.

Improve Content Comprehension

Gradients can improve visual communication. The transition from orange to pink in Symodd’s example below gives depth and contrast to the interface, and it creates some eye-catching visual effects. The shift from light to dark follows the natural scanning patterns of the human eye, moving from the top left of the page to the bottom right.

Create a Pseudo 3D Effect

While the flat aesthetic is sleek and easy to look at, one potential shortcoming is that it lacks an element of realism. To compensate, designers often use gradients to give depth to their backgrounds. This will likely continue to grow as designers try to incorporate more realism and 3D elements into web design.

Try a Gradient Accent

While gradients are often used as backgrounds for pages, they can work in smaller places as well. Consider using a gradient as an accent in navigation, for a secondary image or for specific types of content. Smaller areas of gradient give you more freedom to play with this technique. For example, you could create visually interesting pairs of multicolor, as Bloomberg does:

Overlay

A color overlay is probably the most self-explanatory effect. And it is one of the most useful and commonly used effects in popular design. If you want to incorporate it in your design, all you need to do is cover an image or video with a semi-transparent colored box.

Trendy Look

By using one of the bright, saturated colors associated with material design, you can evoke a feeling of modernism.

Strongest Clickability Signifier

Consider using an image overlay for interactive card-style elements, for video content and for call-to-action buttons.

Focus User Attention

Overlay effects can focus users on certain design elements. However, when using a single color as an overlay, think about the degree of saturation and transparency of the color:

• Heavy color combinations (i.e. less transparency and more saturation) put more focus on the color itself.

• Light combinations put more focus on the image.

Conclusion

Few design elements are more fun to play with than color. Color effects can be dramatic, impressive and even serene. You the designer really get to experiment when using color effects. Whether you are a fan of bright, bold hues or prefer a more minimalist black and white, the one thing to remember is that there are no wrong colors. What matters most is how you use them.

This article is part of the UX design series sponsored by Adobe. Adobe Experience Design CC (Beta) tool is made for a fast and fluid UX design process, as it lets you go from idea to prototype faster. Design, prototype and share — all in one app. You can check out more inspiring projects created with Adobe XD on Behance, and also visit the Adobe XD blog to stay updated and informed.

Editor’s Note: This article originally appeared on Inclusive Components. If you’d like to know more about similar inclusive component articles, follow @inclusicomps on Twitter or subscribe to the RSS feed. By supporting inclusive-components.design on Patreon, you can help to make it the most comprehensive database of robust interface components available.

Some things are either on or off and, when those things aren’t on (or off), they are invariably off (or on). The concept is so rudimentary that I’ve only complicated it by trying to explain it, yet on/off switches (or toggle buttons) are not all alike. Although their purpose is simple, their applications and forms vary greatly.

In this inaugural post, I’ll be exploring what it takes to make toggle buttons inclusive. As with any component, there’s no one way to go about this, especially when such controls are examined under different contexts. However, there’s certainly plenty to forget to do or to otherwise screw up, so let’s try to avoid any of that.

Changing State

If a web application did not change according to the instructions of its user, the resulting experience would be altogether unsatisfactory. Nevertheless, the luxury of being able to make web documents augment themselves instantaneously, without recourse to a page refresh, has not always been present.

Unfortunately, somewhere along the way we decided that accessible web pages were only those where very little happened — static documents, designed purely to be read. Accordingly, we made little effort to make the richer, stateful experiences of web applications inclusive.

A popular misconception has been that screen readers don’t understand JavaScript. Not only is this entirely untrue — all major screen readers react to changes in the DOM as they occur — but basic state changes, communicated both visually and to assistive technology software, do not necessarily depend on JavaScript to take place anyway.

Checkboxes And Radio Buttons

Form elements are the primitives of interactive web pages and, where we’re not employing them directly, we should be paying close attention to how they behave. Their handling of state changes have established usability conventions we would be foolish to ignore.

Arguably, an out-of-the-box input of the checkbox type is a perfectly serviceable on/off switch all its own. Where labelled correctly, it has all the fundamental ingredients of an accessible control: it’s screen reader and keyboard accessible between platforms and devices, and it communicates its change of state (checked to unchecked or vice versa) without needing to rebuild the entire document.

In the following example, a checkbox serves as the toggle for an email notifications setting.

<input type="checkbox" name="notify" value="on"> <label for="notify">Notify by email</label> 

Screen reader software is fairly uniform in its interpretation of this control. On focusing the control (moving to it using the Tab key) something similar to, “Notify by email, checkbox, unchecked” will be announced. That’s the label, role, and state information all present.

On checking the checkbox, most screen reader software will announce the changed state, “checked” (sometimes repeating the label and role information too), immediately. Without JavaScript, we’ve handled state and screen reader software is able to feed back to the user.

Screen readers are not just for the blind

Some operate screen readers to assist their understanding of an interface. Others may be visually dyslexic or have low literacy. There are even those who have little physical or cognitive trouble understanding an interface who simply prefer to have it read out to them sometimes.

Supporting screen reader software is supporting screen reader software, not blind people. Screen readers are a tool a lot of different people like to use.

In this case, the on/off part of the switch is not communicated by the label but the state. Instead, the label is for identifying the thing that we are turning off or on. Should research show that users benefit from a more explicit on/off metaphor, a radio button group can be employed.

<fieldset> <legend>Notify by email</legend> <input type="radio" name="notify" value="on" checked> <label for="notify-on">on</label> <input type="radio" name="notify" value="off"> <label for="notify-off">off</label></fieldset> 

Group labels are a powerful tool. As their name suggests, they can provide a single label to related (grouped) items. In this case, the <fieldset> group element works together with the <legend> element to provide the group label “Notify by email” to the pair of radio buttons. These buttons are made a pair by sharing a name attribute value, which makes it possible to toggle between them using your arrow keys. HTML semantics don’t just add information but also affect behavior.

In the Windows screen readers JAWS and NVDA, when the user focuses the first control, the group label is prepended to that control’s individual label and the grouped radio buttons are enumerated. In NVDA, the term “grouping” is appended to make things more explicit. In the above example, focusing the first (checked by default) radio button elicits, “Notify by email, grouping, on radio button, checked, one of two”.

Now, even though the checked state (announced as “selected” in some screen readers) is still being toggled, what we’re really allowing the user to do it switch between “on” and “off”. Those are the two possible lexical states, if you will, for the composite control.

Styling form elements

Form elements are notoriously hard to style, but there are well-supported CSS techniques for styling radio and checkbox controls, as I wrote in Replacing Radio Buttons Without Replacing Radio Buttons. For tips on how to style select elements and file inputs, consult WTF Forms? by Mark Otto.

This doesn’t quite feel right

Both the checkbox and radio button implementations are tenable as on/off controls. They are, after all, accessible by mouse, touch, keyboard, and assistive technology software across different devices, browsers, and operating systems.

But accessibility is only a part of inclusive design. These controls also have to make sense to users; they have to play an unambiguous role within the interface.

The trouble with using form elements is their longstanding association with the collection of data. That is, checkboxes and radio buttons are established as controls for designating values. When a user checks a checkbox, they may just be switching a state, but they may suspect they are also choosing a value for submission.

Whether you’re a sighted user looking at a checkbox, a screen reader user listening to its identity being announced, or both, its etymology is problematic. We expect toggle buttons to be buttons, but checkboxes and radio buttons are really inputs.

A True Toggle Button

Sometimes we use <button> elements to submit forms. To be fully compliant and reliable these buttons should take the type value of submit.

<button type="submit">Send</button> 

But these are only one variety of button, covering one use case. In truth, <button> elements can be used for all sorts of things, and not just in association with forms. They’re just buttons. We remind ourselves of this by giving them the type value of button.

<button type="button">Send</button> 

The generic button is your go-to element for changing anything within the interface (using JavaScript and without reloading the page) except one’s location within and between documents, which is the purview of links.

Next to links, buttons should be the interactive element you use most prolifically in web applications. They come prepackaged with the “button” role and are keyboard and screen reader accessible by default. Unlike some form elements, they are also trivial to style.

So how do we make a <button> a toggle button? It’s a case of using WAI-ARIA as a progressive enhancement. WAI-ARIA offers states that are not available in basic HTML, such as the pressed state. Imagine a power switch for a computer. When it’s pressed — or pushed in — that denotes the computer is in its “on” state. When it’s unpressed — poking out — the computer must be off.

<button type="button" aria-pressed="true"> Notify by email</button> 

WAI-ARIA state attributes like aria-pressed behave like booleans but, unlike standard HTML state attributes like checked they must have an explicit value of true or false. Just adding aria-pressed is not reliable. Also, the absence of the attribute would mean the unpressed state would not be communicated (a button without the attribute is just a generic button).

You can use this control inside a form, or outside, depending on your needs. But if you do use it inside a form, the type="button" part is important. If it’s not there, some browsers will default to an implicit type="submit" and try to submit the form. You don’t have to use event.preventDefault() on type="button" controls to suppress form submission.

Switching the state from true (on) to false (off) can be done via a simple click handler. Since we are using a <button>, this event type can be triggered with a mouse click, a press of either the Space or Enter keys, or by tapping the button through a touch screen. Being responsive to each of these actions is something built into <button> elements as standard. If you consult the HTMLButtonElement interface, you’ll see that other properties, such as disabled, are also supported out-of-the-box. Where <button> elements are not used, these behaviors have to be emulated with bespoke scripting.

const toggle = document.querySelector('[aria-pressed]');toggle.addEventListener('click', (e) => { let pressed = e.target.getAttribute('aria-pressed') === 'true'; e.target.setAttribute('aria-pressed', String(!pressed));});

A clearer state

An interesting thing happens when a button with the aria-pressed state is encountered by some screen readers: it is identified as a “toggle button” or, in some cases, “push button”. The presence of the state attribute changes the button’s identity.

When focusing the example button with aria-pressed="true" using NVDA, the screen reader announces,“Notify by email, toggle button, pressed”. The “pressed” state is more apt than “checked”, plus we eschew the form data input connotations. When the button is clicked, immediate feedback is offered in the form of “not pressed”.

Styling

The HTML we construct is an important part of the design work we do and the things we create for the web. I’m a strong believer in doing HTML First Prototyping™, making sure there’s a solid foundation for the styled and branded product.

In the case of our toggle button, this foundation includes the semantics and behavior to make the button interoperable with various input (e.g. voice activation software) and output (e.g. screen reader) devices. That’s possible using HTML, but CSS is needed to make the control understandable visually.

Form should follow function, which is simple to achieve in CSS: everything in our HTML that makes our simple toggle button function can also be used to give it form.

• <button> → button element selector
• aria-pressed="true" → [aria-pressed="true"] attribute selector.

In a consistent and, therefore, easy to understand interface, buttons should share a certain look. Buttons should all look like buttons. So, our basic toggle button styles should probably inherit from the button element block:

/* For example... */button { color: white; background-color: #000; border-radius: 0.5rem; padding: 1em 2em;}

There are a number of ways we could visually denote “pressed”. Interpreted literally, we might make the button look pressed in using some inset box-shadow. Let’s employ an attribute selector for this:

[aria-pressed="true"] { box-shadow: inset 0 0 0 0.15rem #000, inset 0.25em 0.25em 0 #fff;}

To complete the pressed/unpressed metaphor, we can use some positioning and box-shadow to make the unpressed button “poke out”. This block should appear above the [aria-prressed="true"] block in the cascade.

[aria-pressed] { position: relative; top: -0.25rem; left: -0.25rem; box-shadow: 0.125em 0.125em 0 #fff, 0.25em 0.25em #000;}

(Note: This styling method is offered just as one idea. You may find that something more explicit, like the use of “on”/“off” labels in an example to follow, is better understood by more users.)

Don’t rely on color alone

“On” is often denoted by a green color, and “off” by red. This is a well-established convention and there’s no harm in incorporating it. However, be careful not to only use color to describe the button’s two states. If you did, some color blind users would not be able to differentiate them.

Focus styles

It’s important buttons, along with all interactive components, have focus styles. Otherwise people navigating by keyboard cannot see which element is in their control and ready to be operated.

The best focus styles do not affect layout (the interface shouldn’t jiggle around distractingly when moving between elements). Typically, one would use outline, but outline only ever draws a box in most browsers. To fit a focus style around the curved corners of our button, a box-shadow is better. Since we are using box-shadow already, we have to be a bit careful: note the two comma-separated box-shadow styles in the pressed-and-also-focused state.

/* Remove the default outline and add the outset shadow */ [aria-pressed]:focus { outline: none; box-shadow: 0 0 0 0.25rem yellow;}/* Make sure both the inset and outset shadow are present */ [aria-pressed="true"]:focus { box-shadow: 0 0 0 0.25rem yellow, inset 0 0 0 0.15rem #000, inset 0.25em 0.25em 0 #fff; }

Changing Labels

The previous toggle button design has a self-contained, unique label and differentiates between its two states using a change in attribution which elicits a style. What if we wanted to create a button that changes its label from “on” to “off” or “play” to “pause”?

It’s perfectly easy to do this in JavaScript, but there are a couple of things we need to be careful about.

1. If the label changes, what happens with the state?
2. If the label is just “on” or “off” (“play” or “pause”; “active” or “inactive”) how do we know what the button actually controls?

In the previous toggle button example, the label described what would be on or off. Where the “what” part is not consistent, confusion quickly ensues: once “off”/unpressed has become “on”/pressed, I have to unpress the “on” button to turn the “off” button back on. What?

As a rule of thumb, you should never change pressed state and label together. If the label changes, the button has already changed state in a sense, just not via explicit WAI-ARIA state management.

In the following example, just the label changes.

const button = document.querySelector('button');button.addEventListener('click', (e) => { let text = e.target.textContent === 'Play' ? 'Pause' : 'Play'; e.target.textContent = text;});

The problem with this method is that the label change is not announced as it happens. That is, when you click the play button, feedback equivalent to “pressed” is absent. Instead, you have to unfocus and refocus the button manually to hear that it has changed. Not an issue for sighted users, but less ergonomic for blind screen reader users.

Play/pause buttons usually switch between a play symbol (a triangle on its side) and a pause symbol (two vertical lines). We could do this while keeping a consistent non-visual label and changing state.

<!-- Paused state --> <button type="button" aria-pressed="false" aria-label="play"> &#x25b6;</button><-- Playing state --> <button type="button" aria-pressed="true" aria-label="play"> &#x23f8;</button> 

Because aria-label overrides the unicode symbol text node, the paused button is announced as something similar to, “Play button, not pressed” and the playing button as ,“Play button, pressed”.

This works pretty well, except for where voice recognition and activation is concerned. In voice recognition software, you typically need to identify buttons by vocalizing their labels. And if a user sees a pause symbol, their first inclination is to say “pause”, not “play”. For this reason, switching the label rather than the state is more robust here.

Auxiliary labeling

In some circumstances, we may want to provide on/off switches which actually read “on/off”. The trick with these is making sure there is a clear association between each toggle switch and a respective, auxiliary label.

Imagine the email notification setting is grouped alongside other similar settings in a list. Each list item contains a description of the setting followed by an on/off switch. The on/off switch uses the terms “on” and “off” as part of its design. Some <span> elements are provided for styling.

<h2>Notifications</h2> <ul> <li> Notify by email <button> <span>on</span> <span>off</span> </button> </li> <li> Notify by SMS <button> <span>on</span> <span>off</span> </button> </li> <li> Notify by fax <button> <span>on</span> <span>off</span> </button> </li> <li> Notify by smoke signal <button> <span>on</span> <span>off</span> </button> </li></ul> 

The virtue of lists is that, both visually and non-visually, they group items together, showing they are related. Not only does this help comprehension, but lists also provide navigational shortcuts in some screen readers. For example, JAWS provides the L (list) and I (list item) quick keys for moving between and through lists.

Each ‘label’ and button is associated by belonging to a common list item. However, not providing an explicit, unique label is dangerous territory — especially where voice recognition is concerned. Using aria-labelledby, we can associate each button with the list’s text:

<h2>Notifications</h2> <ul> <li> <span>Notify by email</span> <button aria-labelledby="notify-email"> <span>on</span> <span>off</span> </button> </li> <li> <span>Notify by SMS</span> <button aria-labelledby="notify-sms"> <span>on</span> <span>off</span> </button> </li> <li> <span>Notify by fax</span> <button aria-labelledby="notify-fax"> <span>on</span> <span>off</span> </button> </li> <li> <span>Notify by smoke signal</span> <button aria-labelledby="notify-smoke"> <span>on</span> <span>off</span> </button> </li></ul> 

Each aria-labelledby value matches the appropriate span id, forming the association and giving the button its unique label. It works much like a <label> element’s for attribute identifying a field’s id.

The switch role

Importantly, the ARIA label overrides each button’s textual content, meaning we can once again employ aria-pressed to communicate state. However, since these buttons are explicitly “on/off” switches, we can instead use the WAI-ARIA switch role, which communicates state via aria-checked.

<h2>Notifications</h2> <ul> <li> <span>Notify by email</span> <button role="switch" aria-checked="true" aria-labelledby="notify-email"> <span>on</span> <span>off</span> </button> </li> <li> <span>Notify by SMS</span> <button role="switch" aria-checked="true" aria-labelledby="notify-sms"> <span>on</span> <span>off</span> </button> </li> <li> <span>Notify by fax</span> <button role="switch" aria-checked="false" aria-labelledby="notify-fax"> <span>on</span> <span>off</span> </button> </li> <li> <span>Notify by smoke signal</span> <button role="switch" aria-checked="false" aria-labelledby="notify-smoke"> <span>on</span> <span>off</span> </button> </li></ul> 

How you would style the active state is quite up to you, but I’d personally save on writing class attributes to the <span>s with JavaScript. Instead, I’d write some CSS using pseudo classes to target the relevant span dependent on the state.

[role="switch"][aria-checked="true"] :first-child, [role="switch"][aria-checked="false"] :last-child { background: #000; color: #fff;}

An interesting thing happens when a button with the aria-pressed state is encountered by some screen readers: it is identified as a “toggle button” or, in some cases, “push button”. The presence of the state attribute changes the button’s identity.

When focusing the example button with aria-pressed="true" using NVDA, the screen reader announces,“Notify by email, toggle button, pressed”. The “pressed” state is more apt than “checked”, plus we eschew the form data input connotations. When the button is clicked, immediate feedback is offered in the form of “not pressed”.

Styling

The HTML we construct is an important part of the design work we do and the things we create for the web. I’m a strong believer in doing HTML First Prototyping™, making sure there’s a solid foundation for the styled and branded product.

In the case of our toggle button, this foundation includes the semantics and behavior to make the button interoperable with various input (e.g. voice activation software) and output (e.g. screen reader) devices. That’s possible using HTML, but CSS is needed to make the control understandable visually.

Form should follow function, which is simple to achieve in CSS: everything in our HTML that makes our simple toggle button function can also be used to give it form.

• <button> → button element selector
• aria-pressed="true" → [aria-pressed="true"] attribute selector.

In a consistent and, therefore, easy to understand interface, buttons should share a certain look. Buttons should all look like buttons. So, our basic toggle button styles should probably inherit from the button element block:

/* For example... */button { color: white; background-color: #000; border-radius: 0.5rem; padding: 1em 2em;}

There are a number of ways we could visually denote “pressed”. Interpreted literally, we might make the button look pressed in using some inset box-shadow. Let’s employ an attribute selector for this:

[aria-pressed="true"] { box-shadow: inset 0 0 0 0.15rem #000, inset 0.25em 0.25em 0 #fff;}

To complete the pressed/unpressed metaphor, we can use some positioning and box-shadow to make the unpressed button “poke out”. This block should appear above the [aria-prressed="true"] block in the cascade.

[aria-pressed] { position: relative; top: -0.25rem; left: -0.25rem; box-shadow: 0.125em 0.125em 0 #fff, 0.25em 0.25em #000;}

(Note: This styling method is offered just as one idea. You may find that something more explicit, like the use of “on”/“off” labels in an example to follow, is better understood by more users.)

Don’t rely on color alone

“On” is often denoted by a green color, and “off” by red. This is a well-established convention and there’s no harm in incorporating it. However, be careful not to only use color to describe the button’s two states. If you did, some color blind users would not be able to differentiate them.

Focus styles

It’s important buttons, along with all interactive components, have focus styles. Otherwise people navigating by keyboard cannot see which element is in their control and ready to be operated.

The best focus styles do not affect layout (the interface shouldn’t jiggle around distractingly when moving between elements). Typically, one would use outline, but outline only ever draws a box in most browsers. To fit a focus style around the curved corners of our button, a box-shadow is better. Since we are using box-shadow already, we have to be a bit careful: note the two comma-separated box-shadow styles in the pressed-and-also-focused state.

/* Remove the default outline and add the outset shadow */ [aria-pressed]:focus { outline: none; box-shadow: 0 0 0 0.25rem yellow;}/* Make sure both the inset and outset shadow are present */ [aria-pressed="true"]:focus { box-shadow: 0 0 0 0.25rem yellow, inset 0 0 0 0.15rem #000, inset 0.25em 0.25em 0 #fff; }

Changing Labels

The previous toggle button design has a self-contained, unique label and differentiates between its two states using a change in attribution which elicits a style. What if we wanted to create a button that changes its label from “on” to “off” or “play” to “pause”?

It’s perfectly easy to do this in JavaScript, but there are a couple of things we need to be careful about.

1. If the label changes, what happens with the state?
2. If the label is just “on” or “off” (“play” or “pause”; “active” or “inactive”) how do we know what the button actually controls?

In the previous toggle button example, the label described what would be on or off. Where the “what” part is not consistent, confusion quickly ensues: once “off”/unpressed has become “on”/pressed, I have to unpress the “on” button to turn the “off” button back on. What?

As a rule of thumb, you should never change pressed state and label together. If the label changes, the button has already changed state in a sense, just not via explicit WAI-ARIA state management.

In the following example, just the label changes.

const button = document.querySelector('button');button.addEventListener('click', (e) => { let text = e.target.textContent === 'Play' ? 'Pause' : 'Play'; e.target.textContent = text;});

The problem with this method is that the label change is not announced as it happens. That is, when you click the play button, feedback equivalent to “pressed” is absent. Instead, you have to unfocus and refocus the button manually to hear that it has changed. Not an issue for sighted users, but less ergonomic for blind screen reader users.

Play/pause buttons usually switch between a play symbol (a triangle on its side) and a pause symbol (two vertical lines). We could do this while keeping a consistent non-visual label and changing state.

<!-- Paused state --> <button type="button" aria-pressed="false" aria-label="play"> &#x25b6;</button><-- Playing state --> <button type="button" aria-pressed="true" aria-label="play"> &#x23f8;</button> 

Because aria-label overrides the unicode symbol text node, the paused button is announced as something similar to, “Play button, not pressed” and the playing button as ,“Play button, pressed”.

This works pretty well, except for where voice recognition and activation is concerned. In voice recognition software, you typically need to identify buttons by vocalizing their labels. And if a user sees a pause symbol, their first inclination is to say “pause”, not “play”. For this reason, switching the label rather than the state is more robust here.

Auxiliary labeling

In some circumstances, we may want to provide on/off switches which actually read “on/off”. The trick with these is making sure there is a clear association between each toggle switch and a respective, auxiliary label.

Imagine the email notification setting is grouped alongside other similar settings in a list. Each list item contains a description of the setting followed by an on/off switch. The on/off switch uses the terms “on” and “off” as part of its design. Some <span> elements are provided for styling.

<h2>Notifications</h2> <ul> <li> Notify by email <button> <span>on</span> <span>off</span> </button> </li> <li> Notify by SMS <button> <span>on</span> <span>off</span> </button> </li> <li> Notify by fax <button> <span>on</span> <span>off</span> </button> </li> <li> Notify by smoke signal <button> <span>on</span> <span>off</span> </button> </li></ul> 

The virtue of lists is that, both visually and non-visually, they group items together, showing they are related. Not only does this help comprehension, but lists also provide navigational shortcuts in some screen readers. For example, JAWS provides the L (list) and I (list item) quick keys for moving between and through lists.

Each ‘label’ and button is associated by belonging to a common list item. However, not providing an explicit, unique label is dangerous territory — especially where voice recognition is concerned. Using aria-labelledby, we can associate each button with the list’s text:

<h2>Notifications</h2> <ul> <li> <span>Notify by email</span> <button aria-labelledby="notify-email"> <span>on</span> <span>off</span> </button> </li> <li> <span>Notify by SMS</span> <button aria-labelledby="notify-sms"> <span>on</span> <span>off</span> </button> </li> <li> <span>Notify by fax</span> <button aria-labelledby="notify-fax"> <span>on</span> <span>off</span> </button> </li> <li> <span>Notify by smoke signal</span> <button aria-labelledby="notify-smoke"> <span>on</span> <span>off</span> </button> </li></ul> 

Each aria-labelledby value matches the appropriate span id, forming the association and giving the button its unique label. It works much like a <label> element’s for attribute identifying a field’s id.

The switch role

Importantly, the ARIA label overrides each button’s textual content, meaning we can once again employ aria-pressed to communicate state. However, since these buttons are explicitly “on/off” switches, we can instead use the WAI-ARIA switch role, which communicates state via aria-checked.

<h2>Notifications</h2> <ul> <li> <span>Notify by email</span> <button role="switch" aria-checked="true" aria-labelledby="notify-email"> <span>on</span> <span>off</span> </button> </li> <li> <span>Notify by SMS</span> <button role="switch" aria-checked="true" aria-labelledby="notify-sms"> <span>on</span> <span>off</span> </button> </li> <li> <span>Notify by fax</span> <button role="switch" aria-checked="false" aria-labelledby="notify-fax"> <span>on</span> <span>off</span> </button> </li> <li> <span>Notify by smoke signal</span> <button role="switch" aria-checked="false" aria-labelledby="notify-smoke"> <span>on</span> <span>off</span> </button> </li></ul> 

How you would style the active state is quite up to you, but I’d personally save on writing class attributes to the <span>s with JavaScript. Instead, I’d write some CSS using pseudo classes to target the relevant span dependent on the state.

[role="switch"][aria-checked="true"] :first-child, [role="switch"][aria-checked="false"] :last-child { background: #000; color: #fff;}

Traversing the settings

Now let’s talk about navigating through this settings section using two different strategies: by Tab key (jumping between focusable elements only) and browsing by screen reader (moving through each element).

Even when navigating by Tab key, it’s not only the identity and state of the interactive elements you are focusing that will be announced in screen readers. For example, when you focus the first <button>, you’ll hear that it is a switch with the label “Notify by email”, in its on state. “Switch” is the role and aria-checked="true" is vocalized as “on” where this role is present.

Switch role support

The switch role is not quite as well supported as aria-pressed. For example, it is not recognized by the ChromeVox screen reader extension for Chrome.

However, ChromeVox does support aria-checked. This means that, instead of “Switch, Notify by email, on” being announced, “Button, Notify by email, checked” is instead. This isn’t as evocative, but it is adequate. More than likely, it will simply be mistaken for a checkbox input.

Curiously, NVDA regards a button with role="switch" and aria-checked="true" as a toggle button in its pressed state. Since on/off and pressed/unpressed are equivalent, this is acceptable (though slightly disappointing).

But in most screen readers you’ll also be told you’ve entered a list of four items and that you’re on the first item — useful contextual information that works a bit like the group labelling I covered earlier in this post.

Importantly, because we have used aria-labelledby to associate the adjacent text to the button as its label, that is also available when navigating in this mode.

When browsing from item to item (for example, by pressing the down key when the NVDA screen reader is running), everything you encounter is announced, including the heading (“Notifications, heading level two”). Of course, browsing in this fashion, “Notify by email” is announced on its own as well as in association with the adjacent button. This is somewhat repetitive, but makes sense: “Here’s the setting name, and here’s the on/off switch for the setting of this name.”

How explicitly you need to associate controls to the things they control is a finer point of UX design and worth considering. In this case we’ve preserved our classic on/off switches for sighted users, without confusing or misleading either blind or sighted screen reader users no matter which keyboard interaction mode they are using. It’s pretty robust.

Conclusion

How you design and implement your toggle buttons is quite up to you, but I hope you’ll remember this post when it comes to adding this particular component to your pattern library. There’s no reason why toggle buttons — or any interface component for that matter — should marginalize the number of people they often do.

You can take the basics explored here and add all sorts of design nuances, including animation. It’s just important to lay a solid foundation first.

Checklist

• Use form elements such as checkboxes for on/off toggles if you are certain the user won’t believe they are for submitting data.
• Use <button> elements, not links, with aria-pressed or aria-checked.
• Don’t change label and state together.
• When using visual “on” and “off” text labels (or similar) you can override these with a unique label via aria-labelledby.
• Be careful to make sure the contrast level between the button’s text and background color meets WCAG 2.0 requirements.

If you’ve ever tried to implement a bulletproof, good-looking file uploader, you might have encountered an issue: uploading an entire folder or folders of files is usually quite a hassle, as files in each folder have to be selected manually. And then some folders might contain sub-folders as well.

Well, we can use webkitdirectory, a non-standard attribute that allows users to pick a directory via a file input. Currently supported in Chrome, Firefox and Edge.

For example, users could just pick a directory, and all files in that directory and its sub-folders would be listed below, represented by their relative path — a demo by Šime Vidas shows how it works. One click to choose them all is enough.

It’s important to note that the attribute is non-standard, so it will not work for everybody. However, it doesn’t break anything as browsers that don’t support it will just ignore it, so you can easily progressively enhance your file upload without relying on the feature being supported everywhere. Being useful in various scenarios, hopefully the attribute will be picked up by and standardized soon, landing in browsers as a directory attribute.

Ah, and if you want to design a slightly better drag’n’drop-experience, Alex Reardon has a few tips on rethinking drag’n’drop altogether. Worth reading!

Further Resources:

• FileAPI
  
  A set of JavaScript libraries for working with files. Multiupload, drag’n’drop and chunked file upload. Images: crop, resize and auto orientation by EXIF.
• Drag and Drop Interaction Ideas
• HTMLInputElement.webkitdirectory
• File and Directory Entries API

We send out this and other useful tips and tricks for designers and developers in our Smashing Email Newsletter — once every two weeks. (Once subscribed, you get a free eBook, too.)

Words are the primary component of content for the web. However, until a short while ago, all we had at our disposal were but a few system fonts. Adding to that, those system typefaces weren’t necessarily coherent from operating system to operating system (OS). Fortunately, Windows, macOS and Linux made up font-wise, and since then, all modern fonts have been compatible across those OS’. There’s no question, the future of web typography looks promising.

And it’s looking more and more promising, too. At the 2016 ATypI conference, the world’s biggest type design conference, Microsoft, Google, Apple and Adobe announced that they have been working on a new iteration of the OpenType standard, called variable fonts. Because it gives a lot more control to the user to modify the typeface depending on the context and device, this new version opens new opportunities for web typography and will close the gap in quality between web and print.

Variable fonts and parametric fonts are tools that will undeniably revolutionize responsive web type. They will allow graphic and web designers to explore shapes and sizes on their own and to tailor typefaces to their needs. Let’s learn the ins and outs of these new tools and how to take control of our typography.

Web Is Not Print With Pixels

When a paradigm shift comes forth, such as a new medium for typography, the first thing it encounters is resistance. We feel like we need to push the status quo to its limit before it can break free and make room for a new way of thinking. Typography is no exception, and for a long time designers have considered screen as paper made of pixels instead of trees. Typefaces used on computers were, and still are for the most part, just a static embodiment of physical fonts. Sure, the screen medium brought with it a number of necessary and extra elements, such as hinting, but the legacy of physical fonts still resonate strongly in type design.

Still, it feels like digital typography is behind physical typography on a range of issues, not so much in the diversity or quality of design, but in the huge fragmentation of screen media. For print design, a cast of physical fonts could be optimized depending on the sizes and shapes of the letters to increase readability. Once the fonts were produced, the result was the same every time; you got exactly what you paid for.

On a screen, it’s a lot more complicated. Once you’re lost in a forest of DPI values and different renderers, what the user gets is all up in the air. And because type designers have little incentive to produce different optical sizes, a lot of digital typefaces include only a couple of them, which hinders the readability of web typography.

When a graphic designer works on a poster, they already know how it will be displayed or distributed. They know the size of the poster, the size of the font, the colors they will use, etc. All of these are known variables that will contribute to their design choices. Also, the designer knows that, once it’s done and printed, the design will not change, and all viewers will experience the same poster.

Let’s look at another aspect that is difficult to fix in web typography: rags. Rags are easy to deal with in print: You can adjust the tracking a bit, insert line breaks or hyphenate to clean up the rags. Unfortunately, achieving this degree of detail in web typography is more complicated. The width changes, and the font size can be changed by the user. The dynamism of web pages makes it difficult to make the right choice of size, letter-spacing, etc.

Fortunately, it is possible to gather some data about the context in which your website will be browsed. Thanks to CSS and JavaScript, you can adapt the typography of a web page. However, as easy as it is to change the size of a typeface gradually, it is still impossible to easily change from one variant to another progressively. The only option left is to set up breakpoints, with one variant on one side and another on the other side.

Loading more variants has a price. Adding 150 KB of fonts might not seem like a bad trade-off, but it compounds every time you add a new font to the website. Because loading time is a major factor in the bounce rate of a page, you wouldn’t want users to bail just because your web page has too much to load.

Responsive Web Type Technologies

Having described the challenges of web typography, let’s dive into the heart of the matter. We’ll go deep into the two main technologies that help us make great typography for the web: variable fonts and parametric fonts.

Variable Fonts

With the ATypI 2016 conference on variable fonts, variable fonts have made a big entrance on the web. They’re pushed by the biggest names in web browsing (Google, Adobe, Apple and Microsoft), and they are here to stay.

If you want to see what people do with and say about variable fonts, we’ve gathered resources from around the web. You’ll have to use a browser that supports variable fonts, either Chrome from version 59.0 or Firefox from version 53.0:

• Axis-Praxis (variable fonts playground)
• “Typographic Potential of Variable Fonts,” Alphabettes
• “Decovar, A Multistyle Decorative Variable Font by David Berlow,” TypeNetwork
• Zeitung (variable font), Underware

The best source of news on variable fonts is, without question, the Twitter feed led by Nick Sherman, who collects everything on the web about variable fonts (and for which we should be grateful).

Thanks to the new variable fonts format, it will be possible to precisely adapt typography to its context. Variable fonts are based on a pretty simple idea: They contain several variants of a single typeface or, more precisely, a master variant and deltas from other ones, and the user is free to choose an interpolation of these different versions using only CSS. For example, the typeface could contain a light variant and a bold variant, and you would be able to choose a weight between these light and bold weights using CSS, like so:

 h2 { font-variation-settings: "wght" 200;}

Variable fonts are picky. For them to work, all masters of the font’s base variants must have exactly the same number of points. Morphing between two shapes will be smooth and unique only if the shape you start from and the shape you end up with are similar. Nevertheless, some type creators are used to designing for masters for variable fonts. A similar concept was used for Adobe’s “multiple master” format, and type designers use interpolation to create extended families with tools such as Superpolator. Yet font-variation-settings is still not prevalent in web browsers, and as of the time of writing, only Firefox has implemented the feature. But others should soon follow suit.

There are still a lot of hurdles to jump before variable fonts become an integral part of responsive web typography. Making them is a long endeavor, and type designers now have to think about variations from the get go in order to create typefaces that take full advantage of these new features. Even though converting old typefaces to variable fonts is possible, the old ways are not necessarily suited to the new and more relevant uses that we’ve discussed:

• generating grades on the spot for screens with different DPI.
• changing the width of a typeface depending on the way the user wants to fill lines,
• modifying the optical size depending on the font’s size.

Unfortunately, variable fonts don’t solve every problem with responsive web typography. For example, how do we reduce the number of media queries? How do we handle outliers? How do we make the typeface a part of the web page?

Parametric fonts are intended to fix these issues. They differ from variable fonts in concept and production. They put customization logic at the heart of the font, instead of letting a software do the transformation. All typographic rules are inherently a part of the font, but the font is still easily customizable on the user’s side.

Parametric Fonts

Parametric fonts are an old idea that seems to be revisited regularly by people from different backgrounds. It looks to solve the same issues that variable fonts solve but coming from a more automated way of thinking. So, it has usually been a subject tackled by computer scientists who take an interest in type design.

As with variable fonts, we’ve gathered links from around the web that deal with parametric fonts and their history:

• “Metafont,” Wikipedia
  
  The father of all modern parametric typeface frameworks
• Metaflop
  
  A Metafont graphics interface
• Metapolator
  
  A parametric typeface creation tool based on Metaflop
• “Parametric TrueType Fonts,” TrueType Typography
  
  Information about the now discontinued FontChameleon, which is font software that let you merge fonts from a wide library
• Elementar, Typotheque
  
  A bitmap parametric font

It’s been almost 40 years since Donald Knuth pioneered the concept of parametric fonts. By creating Metafont and Tex, Knuth opened up a new era of typography, in which typefaces were created using a series of steps and equations to describe each character.

That’s the big difference between variable fonts and parametric fonts. Variable fonts are interpolated, meaning that they are confined in a design space. The designer is not able to escape this space; moreover, adding dimensions to it requires the type designer to create a new master (i.e. a completely new font). Parametric fonts are extrapolated, meaning that they emerge from a single definition. The space in which they live is not limited because they behave like a mathematical object.

Take the simple example of a circle. In a variable font world, the type designer would produce two circles and tell you, “Choose either of these circles.” In a parametric font world, the type designer would tell you, “Give the font a radius, and it will produce a circle of that radius.”

Adding a new dimension to your design space is easy with parametric fonts. For variable fonts, it would mean creating a new master. For a parametric font, you just have to bake the new dimension into the existing equations.

It is also easy to add constraints or to alter the rate of change of some points using parametric fonts. As well, you can add logic directly into the font.

How To Start Working With Parametric Fonts?

Parametric fonts are pretty easy to use, and the result can look gorgeous. As we’ll see in the examples, parametric fonts can mitigate optical differences between different colors of text. You can also create text that responds to its context or to any interface you can imagine.

To make life easier for you, we’ve created Prototypo, a free web application for tweaking and adjusting parametric fonts. You’ll need a subscription to take full advantage of parametric fonts. But in the free version, you’ll be able to use subsetted fonts that contain lowercase and uppercase glyphs (no diacritics or figures). The paid subscription unlocks the full fonts.

Here’s how to start experimenting with parametric fonts:

• Use our web preview extension to test your parametric font directly on your website.
• Embed a parametric font on your website using our JavaScript library.

Prototypo Chrome Extension

The extension can be used to try out parameters for different display sizes and layouts. The extension lets you replace the typefaces on your website. All of the modifications you do in Prototypo are applied to your website in real time. This is the perfect tool to try out different optical weights and widths for your fonts in their final context.

Prototypo Parametric Typeface Library

The other option is to use Prototypo parametric technology directly. We’ll explain how you can add the Prototypo library to your website. You’ll be able to create parametric fonts on your website and make them interact as your users need. You can see examples of the parametric technology in our lab. For example, you can use a Kinect to generate fonts, or morph and switch letters based on the current timestamp. We’ll discuss how it works and how you can use it in your projects, including how to:

• set up the project,
• create a font on the fly,
• use the created font in CSS,
• modify the font with JavaScript.

Set Up the Project

This is the tag you will have to add to your HTML to import the Prototypo library.

<script type="application/javascript" src="https://library.prototypo.io/ptypo.js"></script>

You can also import this script asynchronously, but you’ll have to wait for its load event to use the library:

<script async type="application/javascript" src="https://library.prototypo.io/ptypo.js"></script><script type="application/javascript"> document.getElementById('script').addEventListener('load', function() { // You’ll have access to the Ptypo global variable here });</script>

So, what can this library do for you, you ask? Well, it will create a Ptypo global variable that we will use to create our parametric font.

Let’s look at an example to better understand how we can use the library.

Making a Light-Font Mode and a Dark-Font Mode

See the Pen bRKbxY by Francois Poizat (@FranzPoize) on CodePen.

For the first example, we will try to create a font whose weight looks the same whether written in dark on light or light on dark. Text tends to look bolder when written light on dark because light colors tend to bleed on dark colors, making the lighter font seem heavier.

We’ll make a simple HTML document that can be switched from light mode to dark mode, and we will change the parameters of the font accordingly. You could also have several color schemes and produce parameters that would look the same for each color scheme.

Let’s start by creating our font factory.

const ptypoFactory = new Ptypo.default();

Here, you can use your token if you subscribe to the Prototypo application. (You can find more information about that in our documentation.)

Once we have our font factory, it’s time to start creating fonts. For the dynamic part of this example, we’ll create two fonts — named titleFont and paragraphFont for the h1 heading and the paragraph, respectively.

ptypoFactory.createFont( 'titleFont', Ptypo.templateNames.ELZEVIR).then(function(font) { //Setting up the right parameters font.changeParam('thickness', 110);});ptypoFactory.createFont( 'paragraphFont', Ptypo.templateNames.GROTESK).then(function(font) { font.changeParams({thickness: 70, spacing: 0.5});});

The title font uses the Elzevir template, which is a serif template, and the paragraph font uses the Grotesk template, which is a sans-serif. We can set the parameters as we please (you can change the value if you want).

As you can see, we can modify the parameters in two ways:

font.changeParam('nameOfParameter', parameterValue)font.changeParams({ parameter1: parameter1Value, parameter2: parameter2Value, parameter3: parameter3Value …});

You can learn more about the different parameters available in our API documentation.

Now we need to write the HTML that goes with it and the CSS that will assign the correct font to the correct element.

<div> <h1> With Param </h1> <p> Lorem ipsum dolor sit amet.. </p></div>

h1 { font-size: 100px; font-family: 'titleFont'; font-weight: normal;}p { font-size: 18px; line-height: 24px; font-family: 'paragraphFont';}

Here, we’ve created a heading and a paragraph of text and attached the correct font to them: titleFont for the heading and paragraphFont for the paragraph.

We now need to create a button to switch between light and dark mode and create the functions that will modify the fonts.

<a href=”#”> Dark mode</a>

There are many ways to modify our fonts. What we will do is create an array that we will fill with an object literal containing our functions once the fonts are created.

const fontToggles = [];ptypoFactory.createFont( 'titleFont', Ptypo.templateNames.ELZEVIR).then(function(font) { //Setting up the right parameters font.changeParam('thickness', 110); //Storing the function that will be used to change from light to dark //and vice versa fontToggles.push({ lightMode: function() { font.changeParam('thickness', 110); }, darkMode: function() { font.changeParam('thickness', 107); }, });});ptypoFactory.createFont( 'paragraphFont', Ptypo.templateNames.GROTESK).then(function(font) { font.changeParams({thickness: 70, spacing: 0.5}); fontToggles.push({ lightMode: function() { font.changeParam('thickness', 70); }, darkMode: function() { font.changeParam('thickness', 50); }, });});

In this part, we start by creating a font using the ptypoFactory.createFont method.

Ptypo.templateNames.ELZEVIR).then(function(font) { ...});

Once the font is created, we put in default parameters for the thickness. We’ve decided to put a thickness of 110 for the heading font and a thickness of 70 and a spacing of 0.5 for the paragraph font.

font.changeParams({thickness: 70, spacing: 0.5});

For each font, we will add an object to the fontToggles array. This object will contain a lightMode and a darkMode property. These two functions are to be executed when the page enters light mode and dark mode, respectively, using our button.

fontToggles.push({ lightMode: function() { font.changeParam('thickness', 70); }, darkMode: function() { font.changeParam('thickness', 50); },});

Now we can add our listener on the click event of the button and use the functions contained in the array to modify our font according the mode we are in.

let button = document.getElementById('dark-button');button.addEventListener('click', function(e) { document.body.classList.toggle('dark'); fontToggles.forEach(function(toggle) { toggle[document.body.classList.contains('dark') ? 'darkMode' : 'lightMode'](); }); e.preventDefault();});

Thanks to this code, once we click on our dark-mode button, it will add the dark class to the body. It will loop through our font, modifying functions and executing the darkMode one if there a dark class on body and executing lightMode if there is no dark class on body.

In our example, we’ve included a font that does not change in dark mode, to show what the difference will be between the regular font and the slightly modified one.

Customize Fonts With Data

In this example, we’re going to create several fonts, one for each city’s weather that we want to display, customized using the temperature and wind speed of the given city. The thickness of the font will be tied to the temperature, and the slant will be tied to the wind speed.

See the Pen ayYevr by Francois Poizat (@FranzPoize) on CodePen.

First, we’ll create a list of the cities we want to display.

const cities = [ 'Lyon', 'Padova', 'Rennes', 'Tokyo', 'Johannesburg', 'Moscow', 'Beijing', 'San Francisco', 'Marrakech', 'Trondheim',];

We’ve chosen cities from around the world, to have a nice range of temperatures and wind speeds.

function yahooApiQuery(city, callback) { if (!city || !callback) { throw new Error('$.YQL(): Parameters may not be undefined'); } const encodedQuery = encodeURIComponent( `select * from weather.forecast where woeid in (select woeid from geo.places(1) where text='${city}')`.toLowerCase() ); const url = `https://query.yahooapis.com/v1/public/yql?q=${encodedQuery}&format=json&diagnostics=true&env=store%3A%2F%2Fdatatables.org%2Falltableswithkeys&callback=?`; $.getJSON(url, callback);};

This function requests the Yahoo weather API (which comes with documentation). We’ll use jQuery’s getJson function to get the JSON from the API.

function getValueAndChangeFont(city, font) { yahooApiQuery( city, function(data) { font.changeParams({ thickness: parseInt(data.query.results.channel.item.condition.temp) * 2, slant: parseInt(data.query.results.channel.wind.speed), }); } );}

We’ve created a function that takes the name of a city and the font. Then, we’ve requested the weather for this city and changed the parameters of the font according to the temperature and wind speed.

font.changeParams({ thickness: parseInt(data.query.results.channel.item.condition.temp) * 2, slant: parseInt(data.query.results.channel.wind.speed),});

Prototypo Parametric Typeface Library

The other option is to use Prototypo parametric technology directly. We’ll explain how you can add the Prototypo library to your website. You’ll be able to create parametric fonts on your website and make them interact as your users need. You can see examples of the parametric technology in our lab. For example, you can use a Kinect to generate fonts, or morph and switch letters based on the current timestamp. We’ll discuss how it works and how you can use it in your projects, including how to:

• set up the project,
• create a font on the fly,
• use the created font in CSS,
• modify the font with JavaScript.

Set Up the Project

This is the tag you will have to add to your HTML to import the Prototypo library.

<script type="application/javascript" src="https://library.prototypo.io/ptypo.js"></script>

You can also import this script asynchronously, but you’ll have to wait for its load event to use the library:

<script async type="application/javascript" src="https://library.prototypo.io/ptypo.js"></script><script type="application/javascript"> document.getElementById('script').addEventListener('load', function() { // You’ll have access to the Ptypo global variable here });</script>

So, what can this library do for you, you ask? Well, it will create a Ptypo global variable that we will use to create our parametric font.

Let’s look at an example to better understand how we can use the library.

Making a Light-Font Mode and a Dark-Font Mode

See the Pen bRKbxY by Francois Poizat (@FranzPoize) on CodePen.

For the first example, we will try to create a font whose weight looks the same whether written in dark on light or light on dark. Text tends to look bolder when written light on dark because light colors tend to bleed on dark colors, making the lighter font seem heavier.

We’ll make a simple HTML document that can be switched from light mode to dark mode, and we will change the parameters of the font accordingly. You could also have several color schemes and produce parameters that would look the same for each color scheme.

Let’s start by creating our font factory.

const ptypoFactory = new Ptypo.default();

Here, you can use your token if you subscribe to the Prototypo application. (You can find more information about that in our documentation.)

Once we have our font factory, it’s time to start creating fonts. For the dynamic part of this example, we’ll create two fonts — named titleFont and paragraphFont for the h1 heading and the paragraph, respectively.

ptypoFactory.createFont( 'titleFont', Ptypo.templateNames.ELZEVIR).then(function(font) { //Setting up the right parameters font.changeParam('thickness', 110);});ptypoFactory.createFont( 'paragraphFont', Ptypo.templateNames.GROTESK).then(function(font) { font.changeParams({thickness: 70, spacing: 0.5});});

The title font uses the Elzevir template, which is a serif template, and the paragraph font uses the Grotesk template, which is a sans-serif. We can set the parameters as we please (you can change the value if you want).

As you can see, we can modify the parameters in two ways:

font.changeParam('nameOfParameter', parameterValue)font.changeParams({ parameter1: parameter1Value, parameter2: parameter2Value, parameter3: parameter3Value …});

You can learn more about the different parameters available in our API documentation.

Now we need to write the HTML that goes with it and the CSS that will assign the correct font to the correct element.

<div> <h1> With Param </h1> <p> Lorem ipsum dolor sit amet.. </p></div>

h1 { font-size: 100px; font-family: 'titleFont'; font-weight: normal;}p { font-size: 18px; line-height: 24px; font-family: 'paragraphFont';}

Here, we’ve created a heading and a paragraph of text and attached the correct font to them: titleFont for the heading and paragraphFont for the paragraph.

We now need to create a button to switch between light and dark mode and create the functions that will modify the fonts.

<a href=”#”> Dark mode</a>

There are many ways to modify our fonts. What we will do is create an array that we will fill with an object literal containing our functions once the fonts are created.

const fontToggles = [];ptypoFactory.createFont( 'titleFont', Ptypo.templateNames.ELZEVIR).then(function(font) { //Setting up the right parameters font.changeParam('thickness', 110); //Storing the function that will be used to change from light to dark //and vice versa fontToggles.push({ lightMode: function() { font.changeParam('thickness', 110); }, darkMode: function() { font.changeParam('thickness', 107); }, });});ptypoFactory.createFont( 'paragraphFont', Ptypo.templateNames.GROTESK).then(function(font) { font.changeParams({thickness: 70, spacing: 0.5}); fontToggles.push({ lightMode: function() { font.changeParam('thickness', 70); }, darkMode: function() { font.changeParam('thickness', 50); }, });});

In this part, we start by creating a font using the ptypoFactory.createFont method.

Ptypo.templateNames.ELZEVIR).then(function(font) { ...});

Once the font is created, we put in default parameters for the thickness. We’ve decided to put a thickness of 110 for the heading font and a thickness of 70 and a spacing of 0.5 for the paragraph font.

font.changeParams({thickness: 70, spacing: 0.5});

For each font, we will add an object to the fontToggles array. This object will contain a lightMode and a darkMode property. These two functions are to be executed when the page enters light mode and dark mode, respectively, using our button.

fontToggles.push({ lightMode: function() { font.changeParam('thickness', 70); }, darkMode: function() { font.changeParam('thickness', 50); },});

Now we can add our listener on the click event of the button and use the functions contained in the array to modify our font according the mode we are in.

let button = document.getElementById('dark-button');button.addEventListener('click', function(e) { document.body.classList.toggle('dark'); fontToggles.forEach(function(toggle) { toggle[document.body.classList.contains('dark') ? 'darkMode' : 'lightMode'](); }); e.preventDefault();});

Thanks to this code, once we click on our dark-mode button, it will add the dark class to the body. It will loop through our font, modifying functions and executing the darkMode one if there a dark class on body and executing lightMode if there is no dark class on body.

In our example, we’ve included a font that does not change in dark mode, to show what the difference will be between the regular font and the slightly modified one.

Customize Fonts With Data

In this example, we’re going to create several fonts, one for each city’s weather that we want to display, customized using the temperature and wind speed of the given city. The thickness of the font will be tied to the temperature, and the slant will be tied to the wind speed.

See the Pen ayYevr by Francois Poizat (@FranzPoize) on CodePen.

First, we’ll create a list of the cities we want to display.

const cities = [ 'Lyon', 'Padova', 'Rennes', 'Tokyo', 'Johannesburg', 'Moscow', 'Beijing', 'San Francisco', 'Marrakech', 'Trondheim',];

We’ve chosen cities from around the world, to have a nice range of temperatures and wind speeds.

function yahooApiQuery(city, callback) { if (!city || !callback) { throw new Error('$.YQL(): Parameters may not be undefined'); } const encodedQuery = encodeURIComponent( `select * from weather.forecast where woeid in (select woeid from geo.places(1) where text='${city}')`.toLowerCase() ); const url = `https://query.yahooapis.com/v1/public/yql?q=${encodedQuery}&format=json&diagnostics=true&env=store%3A%2F%2Fdatatables.org%2Falltableswithkeys&callback=?`; $.getJSON(url, callback);};

This function requests the Yahoo weather API (which comes with documentation). We’ll use jQuery’s getJson function to get the JSON from the API.

function getValueAndChangeFont(city, font) { yahooApiQuery( city, function(data) { font.changeParams({ thickness: parseInt(data.query.results.channel.item.condition.temp) * 2, slant: parseInt(data.query.results.channel.wind.speed), }); } );}

We’ve created a function that takes the name of a city and the font. Then, we’ve requested the weather for this city and changed the parameters of the font according to the temperature and wind speed.

font.changeParams({ thickness: parseInt(data.query.results.channel.item.condition.temp) * 2, slant: parseInt(data.query.results.channel.wind.speed),});

We’ve multiplied the temperature by two because most temperatures in Fahrenheit are between 0 and 100 degrees, and we want the thickness to be between 0 and 200, so that the contrast is stronger. We’ve left the speed of the wind untouched because it can probably take values from 0 to 40, which would be great as an angle for the slant.

const ptypoFactory = new Ptypo.default();cities.forEach(function(city) { $('#city-names').append( `${city} ` ); ptypoFactory.createFont( `${city}WeatherFont`, Ptypo.templateNames.GROTESK).then( function(font) { getValueAndChangeFont(city, font); } );});

For each city, we create a span element that is styled with the right font family. We then create this font using Prototypo’s library. We go through the same process explained in the first example. Let’s create the factory:

const ptypoFactory = new Ptypo.default();

Then, for each city, we create the city’s font with the correct name, ${city}WeatherFont, using our getValueAndChangeFont function to customize the font.

This simple example shows how Prototypo can be very helpful for designing a new kind of data visualization: creating typefaces that are able to express more than the text, directly linked to data. Feel free to test this Codepen with your own city, to try others parameters (x-height, width, etc.) and to show us what you’ve achieved!

This concludes our examples. If you want to see more experiments we’ve created with the library, head over to our lab.

Conclusion

Parametric font technology will help us improve the user experience by enabling us to optimize how fonts are displayed on all sorts of devices. It also enables us to be more creative with fonts using context, outside variables and physical sensors to modify the input parameters. You just need to find ideas to tailor your typefaces to the experiences you want to provide:

• Create data visualizations that combine text and content. Imagine that your client has a big website about sports. You will be able to produce a design in which the shapes and proportions of fonts used for players’ names could be linked to the number of touchdowns they’ve scored, the number of games they’ve played, etc.
• Improve the user’s browsing experience with responsive fonts and even adaptive fonts. Because we can already set our text-size preferences, we can imagine a future when users have their own profile to fit their reading habits, especially those who have visual impairments.
• Design storefronts that respond to passers by. Design theater plays whose words are shaped directly by the voices of the actors. Design screens that are capable of rendering letters according to the distance of the reader. Parametric fonts are made to interact with people.

Parametric font technology is both complex and powerful, and like every design tool, it goes awry when it’s used without constraint or perspective. But once you get the logic behind it, you will never go back to a simple breakpoint design.

The question now is, What would you do if you could morph typefaces to your every whim?

Editor’s Note: Welcome to this month’s web development update. It’s actually the first one that we publish, and from now on, Anselm will summarize the most important things that happened over the past month in one handy list for you. So that you’re always up to date with what’s going on in the web community. Enjoy!

Today, I’d like to begin this update with a question I’m asking myself quite often, and that was fueled by the things I read lately: Where do we see our responsibility, where do we see other people’s responsibilities? And how do companies fit in here?

With governments needing to make rules for how autonomous cars should behave in case of an incident, we can see how technological progress takes these questions to an entirely new dimension. Or take the Diesel gate affair that has been in the news all over the world these weeks. With software developers facing charges for their work, it showed us how important it is for employees to make their own decisions and to stand up for what’s right instead of blindly doing everything their bosses demand. Of course, this requires us to find our own position, our own path, and to stay true to it. An important thing we should reflect on more often if we want to make a change — not only in our work, but also in our community, and our lives.

News

• Google Chrome 61 brings ECMAScript Modules, navigator.share, the WebUSB API, 8-digit alpha transparency hex-color codes, the CSS scroll-behavior property, and the Visual Viewport API to the browser.
• Android 8, named “Oreo”, is now available and comes with picture-in-picture support, a system-wide autofill feature, and much more. But, unfortunately, it seems that the new version also brings along quite some issues for us web developers, especially problems with Progressive Web Apps, as Maximiliano Firtman points out.
• The latest update of Adobe XD ships with some new features. There’s a new “reuse styles and assets” feature, and character styles created in Photoshop, Illustrator or other Creative Cloud applications can be reused in XD, too. The new version also comes with common UI resources for iOS, Google Material, and Windows.
• Federico Viticci discovered that Apple removed Google AMP versions of a link in iOS 11 and redirects users to the original source URL instead if they are using iMessage or Apple’s Reading List feature. A very interesting step that could be a reaction to users having trouble with AMP URLs or maybe Apple wants to avoid using a third-party proxy that could disappear any time or even change the content of the original URLs.
• At this year’s developer event, Microsoft announced what’s coming in Edge 16: Updated CSS Grid Layout, object-fit and object-position, support for the Payment Request API, Service Workers, and WebVR.

UI/UX

• Jason Fried from Basecamp shares why and how they changed the interface of their Calendar schedule design. Interesting insights into why our idea of what could work doesn’t always equal what will work in practice.
• Feather Icons is a set of 240 simply beautiful open-source icons that come in handy in all kinds of UI projects.
• Thomas Payne shares why the much-hated Comic Sans font isn’t such a bad font after all.

Tooling

• This article by Mozilla describes how you can use Firefox in headless mode and how to run automated tests with it.
• Subfont is a command line tool to statically analyze your page to generate the most optimal web font subsets, then inject them into your page. It’s also part of assetgraph 3.8.
• Martin Tapia explains how you can use headless Chrome to scrape websites and why it’s so much cooler than using curl.

JavaScript

• Diogo Spínola wrote a transition guide for everyone using callbacks to move their code to async/await functions in the future.

CSS

• Adam Wathan summarized how the way he writes CSS transitioned from a very “semantic” approach to what is called “functional CSS”. In the article, he explains how the semantic approach works, which challenges it brings along and then compares the code example with functional approaches.
• Darryl Pogue gives insights into how we can fix website issues caused by the new kind of viewport that was introduced with iPhone X this week.

Web Performance

• Jack Preston wrote up a nice visual explanation of how compression works.

Accessibility

• Adrian Roselli explains what’s new in WCAG2.1 and what you need to know to match the latest accessibility criteria.
• Russ Weakley shares how to build an accessible auto-complete field.

Security

• Some researchers found a way to control voice assistants from Apple, Google, Amazon, Microsoft, Samsung, and Huawei. And this does not only affect the smart home boxes but also every iPhone, MacBook, Windows 10 PC, or Samsung Galaxy phone. By using ultrasonic frequencies, they could control the devices and call people, open websites, and even re-route a navigation system of an Audi Q3 car.
• Stéphane Bortzmeyer shares the observations made during a technical attack against the WikiLeaks platform last week. This is a good example of how DNS attacks work.
• Benjamin Caudill introduces CFire, a script to evade Cloudflare’s “Cloud Security Protections”. The article also shares some very interesting details of how Cloudflare’s security system works.

Privacy

• If you’re embedding tweets on your site, you can add<meta name="twitter:dnt" content="on"> so that Twitter doesn’t track your visitors.
• Privacy International shares new insights into how our data is being used against us. Think of scenarios like banks deciding on creditworthiness by using data from our transaction history or connected cars being hacked while the owner doesn’t know which data is recorded, evaluated or sent to whom.

.

Work & Life

• Ted Neward shares how important it is that we as developers make reasonable and legally correct decisions in our work, regardless of what our bosses tell us to do.
• Melinda Gates reveals that, even though she spent her entire career in technology, she wasn’t prepared for how technology will affect her kids. If she had known and thought more about the effects technology has on children, she would have done a couple of things differently. An interesting story that we should care more about.
• Victor Yocco shares why project retrospectives are so important for a team and how to organize them so that they’re useful. An essential read for everyone who’s not doing retrospectives yet.
• Neil Irwin analyzed a janitors’ job conditions at two top companies, back in the 80s and today — namely at Kodak and Apple. A sad story about inequality and about how so-called “successful” companies achieve their success.

We hope you’ve enjoyed this first monthly Web Development Update. The next one is scheduled for October 13th. Stay tuned!

We love exploring opportunities. While many of us are quite familiar with publications and events surrounding us, we often lack the global perspective on what’s happening in the web industry across the world. For example, do you know what the state of web design in Singapore is? What about front-end events in Kuala Lumpur? What about the acceptance of UX-driven processes in Hong Kong? That’s exactly what we want to find out!

For that reason, we’re happy to have teamed up with our friends at Mozilla for the Developer Roadshow Asia, so we can connect and learn from designers and developers in southeastern Asia. Together, we’re planning on organizing a series of informal, free meetup-style events for people who build for the web. On September 19th to 25th, folks from around the globe will be getting together in Singapore, Ho Chi Minh City, Kuala Lumpur, Penang and Hong Kong. Do join us, won’t you?

So, What’s The Roadshow About?

Five days, four countries, five cities: the Mozilla Developer Roadshow Asia aims to connect local communities and build lasting relationships. With our meet-ups, we’ll explore how agencies and companies in Southeast Asia work, and what their processes are like: from graphic design tools to build tools, frameworks and libraries.

We’ll also dive deep into bleeding edge web technology, such as VR, CSS Grid, Web Assembly and Service Workers. These are only a few of the topics that will be tackled on this journey, and there’ll be plenty of room to address key items that affect the browsers we use every day, too, of course! After the trip, we’ll sum up our findings in detailed articles right here, on yours truly Smashing Magazine.

Schedule

If you happen to be in southeastern Asia this month, please join in as we’d love to meet you! Please check the schedule below to find out when the roadshow is coming to a city near you.

Date	Location	Time
Sept. 19, 2017	Singapore @ PayPal	6:00 PM – 9:00 PM (SST)
Sept. 21, 2017	Ho Chi Minh City, Vietnam @ Dreamplex	6:00 PM – 9:00 PM (ICT)
Sept. 23, 2017	Kuala Lumpur, Malaysia @ MaGIC	10:00 AM – 5:00 PM (MYT)
Sept. 25, 2017	Penang, Malaysia @ CAT	10:00 AM – 5:00 PM (MYT)
Sept. 27, 2017	Hong Kong @ Credit Suisse	7:00 PM – 10:00 PM (HKT)

In case you can’t make it, we’ll be posting updates every now and then on Twitter @smashingmag and our dear friend Sandra Persing will make sure you don’t miss out on what’s happening, too. Make sure to mark your calendars! 😉

Get In Touch!

For those in the know-how and those in the loop, please share your experiences with us! We look forward to learning and exploring what’s happening in Southeast Asia, so feel free to get in touch with us via email anytime: roadshow@smashingmagazine.com — we’d love to learn from you!

If you won’t be able to join us this time, who knows, perhaps we’ll come to your part of the world as well. Stay tuned!

---

_Thanks to Cosima Mielke for helping to prepare this article._