Creasey, D. J. (David J.), author

Brøvig-Hanssen, Ragnhild, author

Powell, John, 1955- author

Meyrick, Julian, author

Jankélévitch, Vladimir, author

McLamore, Alyson, 1960- author

Cipriani, Alessandro, 1959- author

Westerner

Juslin, Patrik N., author

Eriksson, Maria, 1969- author

Hexel, Vasco, 1980- author

Robertson, Donald, author

Quick! Think of the word “developer” or “coder” — what’s the first thing that comes to mind? Maybe a whiteish male in his twenties living in a busy metropolis, wearing a nerdy t-shirt and hoodie? Someone a bit like Mark Zuckerberg? Or maybe a younger Bill Gates or Sergey Brin? Any of the dudes from the HBO series Silicon Valley, perhaps? Certainly no one like me.

By tech standards, I’m old. I’m also female and a mother. I live in a midwestern town you’ve never heard of and will never visit — a town where the cows vastly outnumber the people. My hair color is (almost) natural and is no longer part of the ROYGBIV collection, so I have no perceived conference street cred. I own about a thousand geeky T-shirts, but never actually wear them in public, opting for more “girly” attire (or so was pointed out by a male colleague). On the surface, I look more suited to taking notes at a PTA meeting than writing code. I’m a bit of an outsider. A tech misfit.

So when my 11-year-old daughter finished her recent coding camp and excitedly declared, “Now I’m a real developer, Mom, just like you!” there was the usual parent pride, but also a small piece of me that cringed. Because, as much as I support the STEM fields, and want the next generation of girls to be coding wizard-unicorn-ninjas, I really don’t want my own daughter to be a developer. The rationale behind this bold (and maybe controversial) statement comes from a place of protection. The tech world we live in today is far from perfect. I’ve endured my share of misogyny, self-doubt, and sexual harassment. Why wouldn’t I want to protect her from all of that?

The (diversity) elephant in the (computer) room

You’ve heard this story before: there is not enough diversity in tech. This puzzling trend seems to continue year after year, even though numerous studies show that by including more people from underrepresented communities, a company can increase its innovation, employee retention, and bottom line. Even with the recent push and supposed support for diversity and inclusivity from many Fortune 500 companies, women and female-identifying people still only hold 20% of all top tech jobs.

The data from FY 2018 shows that the number of women in technical roles at three of the top tech giants was 24% for Adobe, 26% for Google, and 22% for Facebook. While these numbers show that there is still not enough representation for women, these numbers do reflect a slight increase from the previous year (FY 2017: Adobe 22%, Google 25%, Facebook 15%). But even with this upward trend of hiring women in tech roles, the marginal growth rate has not caught up with the real world. The tech workforce is seriously out of touch with reality if, in 2019, a demographic (women) that represents more than half the global population is still considered a minority.

Sometimes this lack of diversity at the top level is blamed on a “pipeline” issue. The logic being: “If there are not enough girls who learn to code, then there will not be enough women who can code.” However, programs aimed at teaching girls how to code have skyrocketed in the past few years. Girls now make up about half of the enrollment in high-school coding classes and are scoring almost identically to their male classmates on standardized math and science tests, yet, young women make up only 18% of all Computer Science degrees. I have to wonder if this steep drop in interest has more to do with lack of representation in the tech sphere, than with girls and young women simply not being “smart enough” or “not interested” in working with code? At the very least, the lack of representation certainly doesn’t help.

Of course, the diversity picture becomes even more abysmal when you consider other underrepresented groups such as people of color, people from the LGBTQ community, and people with disabilities. And while I really don’t like glossing over these deeper diversity issues in tech, because they are abundant and are much more grotesque failings than the male/female ratio, I also don’t feel qualified to speak about these issues. I encourage you to look to and value the voices of others who can speak with higher authority on these deeper diversity issues, such as Ire Aderinokun, Taelur Alexis, Imani Barbarin, Angie Jones, Fatima Khalid, Tatiana Mac, Charlie Owen, Cherry Rae, and so many others. And for those readers who are new to the topic of diversity in tech, watch Tatiana Mac’s recent conference talk How Privilege Defines Performance — it’s well worth the 35 minutes of your life.

The four stages in the digital accessibility journey

However you look at it, the numbers don’t lie. There are some pretty significant diversity issues in tech. So how do we fix this issue before the next wave of young developers join the tech workforce? Simple: teach developers to write accessible code.

This may seem like a joke to some and stretch to others, but hear me out. When we talk about accessible code, what we are really talking about at its core is inclusiveness. The actual process of writing accessible code involves rules and standards, tests and tools; but inclusive development is more abstract than that. It’s a shift in thinking. And when we rethink our approach to development, we go beyond just the base level of simple code functionality. We instead think, how is this code consumed? How can we make it even more intelligible and easier for people to use? Inclusive development means making something valuable, not just accessible, to as many people as we can.

That line of thinking is a bit abstract, so let’s go through an example. Let’s say you are tasked with updating the color contrast between the text on a webpage or app and the background. What happens at each stage in the accessibility journey?

Stage 1: Awareness — You are brand new to digital accessibility and are still trying to understand what it is and how you can implement changes in your daily workflow. You may be aware that there is a set of digital accessibility guidelines that other developers follow, but you are a bit hazy on what it all means in a practical sense.

Stage 2: Knowledge — You know a bit more about digital accessibility and feel comfortable using a few testing tools, so you run an automated accessibility test on your website and it flags a possible issue with the color contrast. Based on your awareness of the guidelines, you know the color contrast ratio between the text and the background needs to be a certain number and that you need a tool to test this.

Stage 3: Practice — Feeling more confident in your knowledge of digital accessibility rules and best practices, you use a tool to measure the color contrast ratio between the text and the background. Then based on the output of the tool, you modify the hex code to meet the color contrast ratio guidelines and retest to confirm you have met the accessibility requirements for this issue.

Stage 4: Understanding — You understand that the accessibility guidelines and tools are created with people in mind, and that code is secondary to all of that. One is the means, and the other is the end. In the color contrast example, you understand that people with low-vision or colorblindness need these color contrast changes in order to actually see the words on your web page.

This is a bit of an oversimplification of the process. But I hope you get the gist — that there are different stages of digital accessibility knowledge and understanding. True beginners may not be to even stage one, but I am finding that group rarer and rarer these days. The word about digital accessibility seems to be out! Which is great; but that’s only the first hurdle. What I’m seeing now is that a lot of people stop at Stage 2: Knowledge or Stage 3: Practice — where you are aware of the digital accessibility guidelines, have some testing tools in your back pocket, and know how to fix some of the issues reported, but haven’t quite connected the dots to the humans they impact.

From the standpoint of getting daily stuff done, stages two and three are okay stopping points. But what happens when the things you need to do are too complex for a quick fix, or you have no buy-in from your peers or management? I feel that once we get to Stage 4: Understanding, and really get why these kinds of changes are needed, people will be more motivated to make those changes regardless of the challenges involved. When you arrive at stage four, you have gone beyond knowing the basic rules, testing, and coding. You recognize that digital accessibility is not just a “nice to have” but a “must have” and it becomes about quality of life for real people. This is digital inclusion. This is something you can’t unsee, you can’t unlearn, and you can’t ignore.

Making digital accessibility a priority — not a requirement

In my role as an accessibility trainer, I like to kick-off each session with the question: “What are you hoping to learn today about digital accessibility?” I ask this question to establish a rapport with the audience and to understand where everyone is in their accessibility journey, but I am also evaluating the level of company and individual buy-in too. There is nothing worse than showing up to teach a group that does not care to be taught. If I hear the words “I am only here because I have to be” — I know it will be an uphill battle to get them anywhere close to Stage 4: Understanding, so I mentally regroup and aim for another stage.

In my experience, when companies and their leaders say “Digital accessibility is a requirement,” nine times out of ten there is a motivating factor behind this sweeping declaration (for example, impending litigation, or at least the fear of it). When changes are framed as mandatory and packaged as directives from on high with little additional context, people can be resistant and will find excuses to fight or challenge the declaration, and any change can become an uphill battle. Calling something “mandatory” only speaks to Stage 1: Awareness.

By swapping out one word from the original declaration and saying “Digital accessibility is a priority,” companies and their leaders have reframed the conversation with their employees. When changes are framed as “working towards a solution” and discussed openly and collaboratively, people feel like they are part of the process and are more open to embracing change. In the long run, embracing change becomes part of a company’s culture and leads to innovation (and, yes, inclusion) on all levels. Calling something a priority speaks to Stage 4: Understanding.

Some of the excuses I often hear from clients for not prioritizing accessibility is that it is too difficult, too costly, and/or too time consuming — but is that really the case? In the same accessibility training, I lead an exercise where we look at a website with an accessibility testing tool and review any issues that came up. With the group’s help we plot out the “impact to user” versus the “remediation effort” on the part of the team. From group to group, while the plots are slightly different, one commonality is that close to 80% of the errors plotted fall into the quadrant of “simple to fix” for the team, but they also fall under “high impact” to the user. Based on this empirical data, I won’t buy the argument from clients who say that accessibility is too difficult and costly and time consuming anymore. It comes down to whether it’s a priority — for each individual and for the company as a whole.

What will your coding legacy be?

The infinite monkey theorem states that a monkey hitting keys at random on a typewriter for an infinite amount of time will eventually type any given text, such as the complete works of William Shakespeare. So by that same logic, a programmer hitting keys at random on a computer for an infinite amount of time will almost surely produce a website that is accessible. But where is the thought process? Where is the human element? While all the things we’ve already talked about — awareness, education, and prioritization of accessibility are important steps in making the digital world more inclusive to all — without intent, we are just going to keep randomly tapping away at our computers, repeating the same mistakes over and over again. The intent behind the code has to be part of the process, otherwise accessibility is just another task that has no meaning.

Maybe I’m naive, but I’d like to think we’ve come to a point in our society where we want our work lives to have meaning. And that we don’t want to just hear about the positive change that is happening, but want to be part of the change. Digital accessibility is a place where this can happen! Not only does understanding and writing purpose-driven code help people with disabilities in the short-run, I believe strongly that is key to solving the overarching diversity issue in tech in the long-run. Developers who reach Stage 4: Understanding, and who prioritize accessible code because they understand it’s fundamentally about people, will also be the ones who help create and cultivate an inclusive environment where people from more diverse backgrounds are also prioritized and accepted in the tech world.

Because when you strip away all the styles, all the mark-up, all the cool features from a website or app — what’s left? People. And honestly, the more I learn about digital accessibility, the more I realize it’s not about the code at all. Digital accessibility is rooted in the user; and, while I (and countless others) can certainly teach you how to write accessible code, and build you tools, patterns, and libraries to use, I realize we can’t teach you to care. That is a choice you have to make yourself. So think for a moment — what are you leaving the next generation of developers with all that inaccessible code you haven’t given much thought to? Is it the coding legacy you really want to leave? I challenge you to do better for my daughter, her peers, and for the countless others who are not fully represented in the tech community today.

You’ve done everything you thought was possible to address your website’s JavaScript problem. You relied on the web platform where you could. You sidestepped Babel and found smaller framework alternatives. You whittled your application code down to its most streamlined form possible. Yet, things are just not fast enough. When websites fail to perform the way we as designers and developers expect them to, we inevitably turn on ourselves:

“What are we failing to do?” “What can we do with the code we have written?” “Which parts of our architecture are failing us?”

These are valid inquiries, as a fair share of performance woes do originate from our own code. Yet, assigning blame solely to ourselves blinds us to the unvarnished truth that a sizable onslaught of our performance problems comes from the outside.

When the third wheel crashes the party

Convenience always has a price, and the web is wracked by our collective preference for it.  JavaScript, in particular, is employed in a way that suggests a rapidly increasing tendency to outsource whatever it is that We (the first party) don’t want to do. At times, this is a necessary decision; it makes perfect financial and operational sense in many situations.

But make no mistake, third-party JavaScript is never cheap. It’s a devil’s bargain where vendors seduce you with solutions to your problem, yet conveniently fail to remind you that you have little to no control over the side effects that solution introduces. If a third-party provider adds features to their product, you bear the brunt. If they change their infrastructure, you will feel the effects of it. Those who use your site will become frustrated, and they aren’t going to bother grappling with an intolerable user experience. You can mitigate some of the symptoms of third parties, but you can’t cure the ailment unless you remove the solutions altogether—and that’s not always practical or possible.

In this installment of Responsible JavaScript, we’ll take a slightly less technical approach than in the previous installment. We are going to talk more about the human side of third parties. Then, we’ll go down some of the technical avenues for how you might go about tackling the problem.

Hindered by convenience

When we talk about the sorry state of the web today, some of us are quick to point out the role of developer convenience in contributing to the problem. While I share the view that developer convenience has a tendency to harm the user experience, they’re not the only kind of convenience that can turn a website into a sluggish, janky mess.

Operational conveniences can become precursors to a very thorny sort of technical debt. These conveniences are what we reach for when we can’t solve a pervasive problem on our own. They represent third-party solutions that address problems in the absence of architectural flexibility and/or adequate development resources.

Whenever an inconvenience arises, that is the time to have the discussion around how to tackle it in a way that’s comprehensive. So let’s talk about what it looks like to tackle that sort of scenario from a more human angle.

The problem is pain

The reason third parties come into play in the first place is pain. When a decision maker in an organization has felt enough pain around a certain problem, they’re going to do a very human thing, which is to find the fastest way to make that pain go away.

Markets will always find ways to address these pain points, even if the way they do so isn’t sustainable or even remotely helpful. Web accessibility overlays—third-party scripts that purport to automatically fix accessibility issues—are among the worst offenders. First, you fork over your money for a fix that doesn’t fix anything. Then you pay a wholly different sort of price when that “fix” harms the usability of your website. This is not a screed to discredit the usefulness of the tools some third-party vendors provide, but to illustrate how the adoption of third-party solutions happens, even those that are objectively awful

So when a vendor rolls up and promises to solve the very painful problem we’re having, there’s a good chance someone is going to nibble. If that someone is high enough in the hierarchy, they’ll exert downward pressure on others to buy in—if not circumvent them entirely in the decision-making process. Conversely, adoption of a third-party solution can also occur when those in the trenches are under pressure and lack sufficient resources to create the necessary features themselves.

Whatever the catalyst, it pays to gather your colleagues and collectively form a plan for navigating and mitigating the problems you’re facing.

Create a mitigation plan

Once people in an organization have latched onto a third-party solution, however ill-advised, the difficulty you’ll encounter in forcing a course change will depend on how urgent a need that solution serves. In fact, you shouldn’t try to convince proponents of the solution that their decision was wrong. Such efforts almost always backfire and can make people feel attacked and more resistant to what you’re telling them. Even worse, those efforts could create acrimony where people stop listening to each other completely, and that is a breeding ground for far worse problems to develop.

Grouse and commiserate amongst your peers if you must—as I myself have often done—but put your grievances aside and come up with a mitigation plan to guide your colleagues toward better outcomes. The nooks and crannies of your specific approach will depend on the third parties themselves and the structure of the organization, but the bones of it could look like the following series of questions.

What problem does this solution address?

There’s a reason why a third-party solution was selected, and this question will help you suss out whether the rationale for its adoption is sound. Remember, there are times decisions are made when all the necessary people are not in the room. You might be in a position where you have to react to the aftermath of that decision, but the answer to this question will lead you to a natural follow-up.

How long do we intend to use the solution?

This question will help you identify the solution’s shelf life. Was it introduced as a bandage, with the intent to remove it once the underlying problem has been addressed, such as in the case of an accessibility overlay? Or is the need more long-term, such as the data provided by an A/B testing suite? The other possibility is that the solution can never be effectively removed because it serves a crucial purpose, as in the case of analytics scripts. It’s like throwing a mattress in a swimming pool: it’s easy to throw in, but nigh impossible to drag back out.

In any case, you can’t know if a third-party script is here to stay if you don’t ask. Indeed, if you find out the solution is temporary, you can form a plan to eventually remove it from your site once the underlying problem it addresses has been resolved.

Who’s the point of contact if issues arise?

When a third-party solution is put into place, someone must be the point of contact for when—not if—issues arise.

I’ve seen what happens (far too often) when a third-party script gets out of control. For example, when a tag manager or an A/B testing framework’s JavaScript grows slowly and insidiously because marketers aren’t cleaning out old tags or completed A/B tests. It’s for precisely these reasons that responsibility needs to be attached to a specific person in your organization for third-party solutions currently in use on your site. What that responsibility entails will differ in every situation, but could include:

• periodic monitoring of the third-party script’s footprint;
• maintenance to ensure the third-party script doesn’t grow out of control;
• occasional meetings to discuss the future of that vendor’s relationship with your organization;
• identification of overlaps of functionality between multiple third parties, and if potential redundancies can be removed;
• and ongoing research, especially to identify speedier alternatives that may act as better replacements for slow third-party scripts.

The idea of responsibility in this context should never be an onerous, draconian obligation you yoke your teammates with, but rather an exercise in encouraging mindfulness in your colleagues. Because without mindfulness, a third-party script’s ill effects on your website will be overlooked until it becomes a grumbling ogre in the room that can no longer be ignored. Assigning responsibility for third parties can help to prevent that from happening.

Ensuring responsible usage of third-party solutions

If you can put together a mitigation plan and get everyone on board, the work of ensuring the responsible use of third-party solutions can begin. Luckily for you, the actual technical work will be easier than trying to wrangle people. So if you’ve made it this far, all it will take to get results is time and persistence.

Load only what’s necessary

It may seem obvious, but load only what’s necessary. Judging by the amount of unused first-party JavaScript I see loaded—let alone third-party JavaScript—it’s clearly a problem. It’s like trying to clean your house by stuffing clutter into the closets. Regardless of whether they’re actually needed, it’s not uncommon for third-party scripts to be loaded on every single page, so refer to your point of contact to figure out which pages need which third-party scripts.

As an example, one of my past clients used a popular third-party tool across multiple brand sites to get a list of retailers for a given product. It demonstrated clear value, but that script only needed to be on a site’s product detail page. In reality, it was frequently loaded on every page. Culling this script from pages where it didn’t belong significantly boosted performance for non-product pages, which ostensibly reduced the friction on the conversion path.

Figuring out which pages need which third-party scripts requires you to do some decidedly untechnical work. You’ll actually have to get up from your desk and talk to the person who has been assigned responsibility for the third-party solution you’re grappling with. This is very difficult work for me, but it’s rewarding when good-faith collaboration happens, and good outcomes are realized as a result.

Self-host your third-party scripts

This advice isn’t a secret by any stretch. I even touched on it in the previous installment of this series, but it needs to be shouted from the rooftops at every opportunity: you should self-host as many third-party resources as possible. Whether this is feasible depends on the third-party script in question.

Is it some framework you’re grabbing from Google’s hosted libraries, cdnjs, or other similar provider? Self-host that sucker right now.

Casper found a way to self-host their Optimizely script and significantly reduced their start render time for their trouble. It really drives home the point that a major detriment of third-party resources is the fact that their mere existence on other servers is one of the worst performance bottlenecks we encounter.

If you’re looking to self-host an analytics solution or a similar sort of script, there’s a higher level of difficulty to contend with to self-host it. You may find that some third-party scripts simply can’t be self-hosted, but that doesn’t mean it isn’t worth the trouble to find out. If you find that self-hosting isn’t an option for a third-party script, don’t fret. There are other mitigations you can try.

Mask latency of cross-origin connections

If you can’t self-host your third-party scripts, the next best thing is to preconnect to servers that host them. WebPageTest’s Connection View does a fantastic job of showing you which servers your site gathers resources from, as well as the latency involved in establishing connections to them.

Preconnections are effective because they establish connections to third-party servers before the browser would otherwise discover them in due course. Parsing HTML takes time, and parsers are often blocked by stylesheets and other scripts. Wherever you can’t self-host third-party scripts, preconnections make perfect sense.

Maybe don’t preload third-party scripts

Preloading resources is one of those things that sounds fantastic at first—until you consider its potential to backfire, as Andy Davies points out. If you’re unfamiliar with preloading, it’s similar to preconnecting but goes a step further by instructing the browser to fetch a particular resource far sooner than it ordinarily would.

The drawback of preloading is that while it’s great for ensuring a resource gets loaded as soon as possible, it changes the discovery order of that resource. Whenever we do this, we’re implicitly saying that other resources are less important—including resources crucial to rendering or even core functionality.

It’s probably a safe bet that most of your third-party code is not as crucial to the functionality of your site as your own code. That said, if you must preload a third-party resource, ensure you’re only doing so for third-party scripts that are critical to page rendering.

If you do find yourself in a position where your site’s initial rendering depends on a third-party script, refer to your mitigation plan to see what you can do to eliminate or ameliorate your dependence on it. Depending on a third party for core functionality is never a good position to be in, as you’re relinquishing a lot of control to others who might not have your best interests in mind.

Lazy load non-essential third-party scripts

The best request is no request. If you have a third-party script that doesn’t need to be loaded right away, consider lazy loading it with an Intersection Observer. Here’s what it might look like to lazy load a Facebook Like button when it’s scrolled into the viewport:

let loadedFbScript = false;

const intersectionListener = new IntersectionObserver(entries => {
  entries.forEach(entry => {
    if ((entry.isIntersecting || entry.intersectionRatio) && !loadedFbScript) {
      const scriptEl = document.createElement("script");

      scriptEl.defer = true;
      scriptEl.crossOrigin = "anonymous";
      scriptEl.src = "https://connect.facebook.net/en_US/sdk.js#xfbml=1&version=v3.0";
      scriptEl.onload = () => {
        loadedFbScript = true;
      };
      
      document.body.append(scriptEl);
    }
  });
});

intersectionListener.observe(document.querySelector(".fb-like"));

In the above snippet, we first set a variable to track whether we’ve loaded the Facebook SDK JavaScript. After that, an IntersectionListener is created that checks whether the observed element is in the viewport, and whether the Facebook SDK has been loaded. If the SDK JavaScript hasn’t been loaded, a reference to it is injected into the DOM, which will kick off a request for it.

You’re not going to be able to lazy load every third-party script. Some of them simply need to do their work at page load time, or otherwise can’t be deferred. Regardless, do the detective work to see if it’s possible to lazy load at least some of your third-party JavaScript.

One of the common concerns I hear from coworkers when I suggest lazy loading third-party scripts is how it can delay whatever interactions the third party provides. That’s a reasonable concern, because when you lazy load anything, a noticeable delay may occur as the resource loads. You can get around this to some extent with resource prefetching. This is different than preloading, which we discussed earlier. Prefetching consumes a comparable amount of data, yes, but prefetched resources are given lower priority and are less likely to contend for bandwidth with critical resources.

Staying on top of the problem

Keeping an eye on your third-party JavaScript requires mindfulness bordering on hypervigilance. When you recognize poor performance for the technical debt that it truly is, you’ll naturally slip into a frame of mind where you’ll recognize and address it as you would any other kind of technical debt.

Staying on top of third parties is refactoring—a sort that requires you to periodically perform tasks such as cleaning up tag managers and A/B tests, consolidating third-party solutions, eliminating any that are no longer needed, and applying the coding techniques discussed above. Moreover, you’ll need to work with your team to address this technical debt on a cyclical basis. This kind of work can’t be automated, so yes, you’ll need to knuckle down and have face-to-face, synchronous conversations with actual people.

If you’re already in the habit of scheduling “cleanup sprints” on some interval, then that is the time and space for you to address performance-related technical debt, regardless of whether it involves third- or first-party code. There’s a time for feature development, but that time should not comprise the whole of your working hours. Development shops that focus only on feature development are destined to be wholly consumed by the technical debt that will inevitably result.

So it will come to pass that in the fourth and final installment of this series we’ll discuss what it means to do the hard work of using JavaScript responsibly in the context of process. Therein, we’ll explore what it takes to unite your organization under the banner of making your website faster and more accessible, and therefore more usable for everyone, everywhere.

Writing to meet WCAG2 standards can be a challenge, but it’s worthwhile. Albert Einstein, the archetypical genius and physicist, once said, “Any fool can make things bigger, more complex, and more violent. It takes a touch of genius—and a lot of courage—to move in the opposite direction.”

Hopefully, this entire book will help you better write for accessibility. So far, you’ve learned:

• Why clarity is important
• How to structure messages for error states and stress cases
• How to test the effectiveness of the words you write

All that should help your writing be better for screen readers, give additional context to users who may need it, and be easier to parse.

But there are a few specific points that you may not otherwise think about, even after reading these pages.

Writing for Screen Readers

People with little or no sight interact with apps and websites in a much different way than sighted people do. Screen readers parse the elements on the screen (to the best of their abilities) and read it back to the user. And along the way, there are many ways this could go wrong. As the interface writer, your role is perhaps most important in giving screen reader users the best context.

Here are a few things to keep in mind about screen readers:

• The average reading time for sighted readers is two to five words per second. Screen-reader users can comprehend text being read at an average of 35 syllables per second, which is significantly faster. Don’t be afraid to sacrifice brevity for clarity, especially when extra context is needed or useful.
• People want to be able to skim long blocks of text, regardless of sight or audio, so it’s extremely important to structure your longform writing with headers, short paragraphs, and other content design best practices.

Write Chronologically, Not Spatially

Writing chronologically is about describing the order of things, rather than where they appear spatially in the interface. There are so many good reasons to do this (devices and browsers will render interfaces differently), but screen readers show you the most valuable reason. You’ll often be faced with writing tooltips or onboarding elements that say something like, “Click the OK button below to continue.” Or “See the instructions above to save your document.”

Screen readers will do their job and read those instructions aloud to someone who can’t see the spatial relationships between words and objects. While many times, they can cope with that, they shouldn’t have to. Consider screen reader users in your language. Embrace the universal experience shared by humans and rely on their intrinsic understanding of the top is first, bottom is last paradigm. Write chronologically, as in Figure 5.5.

Rather than saying:

• Click the OK button below to continue.
• (A button that scrolls you to the top of a page): Go to top.

Instead, say:

• Next, select OK to continue.
• Go to beginning.

Write Left to Right, Top to Bottom

While you don’t want to convey spatial meaning in your writing, you still want to keep that spatial order in mind.

Have you ever purchased a service or a product, only to find out later that there were conditions you didn’t know about before you paid for it? Maybe you didn’t realize batteries weren’t included in that gadget, or that signing up for that social network, you were implicitly agreeing to provide data to third-party advertisers.

People who use screen readers face this all the time.

Most screen readers will parse information from left to write, from top to bottom.¹ Think about a few things when reviewing the order and placement of your words. Is there information critical to performing an action, or making a decision, that appears after (to the right or below) an action item, like in Figure 5.5? If so, consider moving it up in the interface.

Instead, if there’s information critical to an action (rules around setting a password, for example, or accepting terms of service before proceeding), place it before the text field or action button. Even if it’s hidden in a tooltip or info button, it should be presented before a user arrives at a decision point.

Don’t Use Colors and Icons Alone

If you are a sighted American user of digital products, there’s a pretty good chance that if you see a message in red, you’ll interpret it as a warning message or think something’s wrong. And if you see a message in green, you’ll likely associate that with success. But while colors aid in conveying meaning to this type of user, they don’t necessarily mean the same thing to those from other cultures.

For example, although red might indicate excitement, or danger in the U.S. (broadly speaking), in other cultures it means something entirely different:

• In China, it represents good luck.
• In some former-Soviet, eastern European countries it’s the color strongly associated with Communism.
• In India, it represents purity.

Yellow, which we in the U.S. often use to mean “caution” (because we’re borrowing a mental model from traffic lights), might convey another meaning for people in other cultures:

• In Latin America, yellow is associated with death.
• In Eastern and Asian cultures, it’s a royal color—sacred and often imperial.

And what about users with color-blindness or low to no vision? And what about screen readers? Intrinsic meaning from the interface color means nothing for them. Be sure to add words that bear context so that if you heard the message being read aloud, you would understand what was being said, as in Figure 5.6.

Describe the Action, Not the Behavior

Touch-first interfaces have been steadily growing and replacing keyboard/mouse interfaces for years, so no longer are users “clicking” a link or a button. But they’re not necessarily “tapping” it either, especially if they’re using a voice interface or an adaptive device.

Instead of microcopy that includes behavioral actions like:

• Click
• Tap
• Press
• See

Try device-agnostic words that describe the action, irrespective of the interface, like:

• Choose
• Select
• View

There are plenty of exceptions to this rule. If your interface requires a certain action to execute a particular function, and you need to teach the user how their gesture affects the interface (“Pinch to zoom out,” for example), then of course you need to describe the behavior. But generally, the copy you’re writing will be simpler and more consistent if you stick with the action in the context of the interface itself.

When I first traveled to Japan as an exchange student in 2001, I lived in northern Kyoto, a block from the Kitayama subway station.

My first time using the train to get to my university was almost a disaster, even though it was only two subway stops away. I thought I had everything I needed to successfully make the trip. I double- and triple-checked that I had the correct change in one pocket and a computer printout of where I was supposed to go in the other. I was able to make it down into the station, but then I just stood at a ticket machine, dumbfounded, looking at all the flashing lights, buttons, and maps above my head (Fig 5.1). Everything was so impenetrable. I was overwhelmed by the architecture, the sounds, the signs, and the language.

My eyes craved something familiar—and there it was. The ticket machine had a small button that said English! I pushed it but became even more lost: the instructions were poorly translated, and anyway, they explained a system that I couldn’t use in the first place.

Guess what saved me? Two little old Japanese ladies. As they bought tickets, I casually looked over their shoulders to see how they were using the machines. First, they looked up at the map to find their desired destination. Then, they noted the fare written next to the station. Finally, they put some money into the machine, pushed the button that lit up with their correct fare, and out popped the tickets! Wow! I tried it myself after they left. And after a few tense moments, I got my ticket and headed through the gates to the train platform.

I pride myself on being a third-culture kid, meaning I was raised in a culture other than the country named on my passport. But even with a cultural upbringing in both Nigeria and the US, it was one of the first times I ever had to guess my way through a task with no previous reference points. And I did it!

Unfortunately, the same guesswork happens online a million times a day. People visit sites that offer them no cultural mental models or visual framework to fall back on, and they end up stumbling through links and pages. Effective visual systems can help eliminate that guesswork and uncertainty by creating layered sets of cues in the design and interface. Let’s look at a few core parts of these design systems and tease out how we can make them more culturally responsive and multifaceted.

Typography

If you work on the web, you deal with typography all the time. This isn’t a book about typography—others have written far more eloquently and technically on the subject. What I would like to do, however, is examine some of the ways culture and identity influence our perception of type and what typographic choices designers can make to help create rich cross-cultural experiences.

Stereotypography

I came across the word stereotypography a few years ago. Being African, I’m well aware of the way my continent is portrayed in Western media—a dirt-poor, rural monoculture with little in the way of technology, education, or urbanization. In the West, one of the most recognizable graphic markers for things African, tribal, or uncivilized (and no, they are not the same thing) is the typeface Neuland. Rob Giampietro calls it “the New Black Face,” a clever play on words. In an essay, he asks an important question:

How did [Neuland and Lithos] come to signify Africans and African-Americans, regardless of how a designer uses them, and regardless of the purpose for which their creators originally intended them? (http://bkaprt.com/ccd/05-01/)

From its release in 1923 and continued use through the 1940s in African-American-focused advertising, Neuland has carried heavy connotations and stereotypes of cheapness, ugliness, tribalism, and roughness. You see this even today. Neuland is used in posters for movies like Tarzan, Jurassic Park, and Jumanji—movies that are about jungles, wildness, and scary beasts lurking in the bush, all Western symbolism for the continent of Africa. Even MyFonts’ download page for Neuland (Fig 5.2) includes tags for “Africa,” “jungle fever,” and “primitive”—tags unconnected to anything else in the product besides that racist history.

Don’t make, use, or sell fonts this way. Here are some tips on how to avoid stereotypography when defining your digital experiences:

• Be immediately suspicious of any typeface that “looks like” a culture or country. For example, so-called “wonton” or “chop-suey” fonts, whose visual style is thought to express “Asianness” or to suggest Chinese calligraphy, have long appeared on food cartons, signs, campaign websites, and even Abercrombie & Fitch T-shirts with racist caricatures of Asians (http://bkaprt.com/ccd/05-03/). Monotype’s website, where you can buy a version called Mandarin Regular (US$35), cringingly describes the typeface’s story as “an interpretation of artistically drawn Asian brush calligraphy” (Fig 5.3). Whether or not you immediately know its history, run away from any typeface that purports to represent an entire culture.

• Support type designers who are from the culture you are designing for. This might seem like it’s a difficult task, but the internet is a big place. I have found that, for clients who are sensitive to cultural issues, the inclusion of type designers’ names and backgrounds can be a powerful differentiator, even making its way into their branding packages as a point of pride.

The world wide webfont

Another common design tool you should consider is webfonts—fonts specifically designed for use on websites and apps. One of the main selling points of webfonts is that instead of putting text in images, clients can use live text on their sites, which is better for SEO and accessibility. They are simple to implement these days, a matter of adding a line of code or checking a box on a templating engine. The easiest way to get them on your site is by using a service like Google Fonts, Fontstand, or Adobe Fonts.

Or is it? That assumes those services are actually available to your users.

Google Fonts (and every other service using Google’s Developer API) is blocked in mainland China, which means that any of those nice free fonts you chose would simply not load (http://bkaprt.com/ccd/05-05/). You can work around this, but it also helps to have a fallback font—that’s what they’re for.

When you’re building your design system, why not take a few extra steps to define some webfonts that are visible in places with content blocks? Justfont is one of the first services focused on offering a wide range of Chinese webfonts (http://bkaprt.com/ccd/05-06/). They have both free and paid tiers of service, similar to Western font services. After setting up an account, you can grab whatever CSS and font-family information you need.

Multiple script systems

When your design work requires more than one script—for instance, a Korean typeface and a Latin typeface—your choices get much more difficult. Designs that incorporate more than one are called multiple script systems (multiscript systems for short). Combining them is an interesting design challenge, one that requires extra typographic sensitivity. Luckily, your multiscript choices will rarely appear on the same page together; you will usually be choosing fonts that work across the brand, not that work well next to one another visually.

Let’s take a look at an example of effective multiscript use. SurveyMonkey, an online survey and questionnaire tool, has their site localized into a variety of different languages (Fig 5.4). Take note of the headers, the structure of the text in the menu and buttons, and how both fonts feel like part of the same brand.

Some tips as you attempt to choose multiscript fonts for your project:

• Inspect the overall weight and contrast level of the scripts. Take the time to examine how weight and contrast are used in the scripts you’re using. Find weights and sizes that give you a similar feel and give the page the right balance, regardless of the script.
• Keep an eye on awkward script features. Character x-heights, descenders, ascenders, and spacing can throw off the overall brand effect. For instance, Japanese characters are always positioned within a grid with all characters designed to fit in squares of equal height and width. Standard Japanese typefaces also contain Latin characters, called romaji. Those Latin characters will, by default, be kerned according to that same grid pattern, often leaving their spacing awkward and ill-formed. Take the extra time to find a typeface that doesn’t have features that are awkward to work with.
• Don’t automatically choose scripts based on superficial similarity. Initial impressions don’t always mean a typeface is the right one for your project. In an interview in the book Bi-Scriptual, Jeongmin Kwon, a typeface designer based in France, offers an example (http://bkaprt.com/ccd/05-09/). Nanum Myeongjo, a contemporary Hangul typeface, might at first glance look really similar to a seventeenth-century Latin old-style typeface—for instance, they both have angled serifs. However, Nanum Myeongjo was designed in 2008 with refined, modern strokes, whereas old-style typefaces were originally created centuries ago and echo handwritten letterforms (http://bkaprt.com/ccd/05-10/). Looking at the Google Fonts page for Nanum Myeongjo, though, none of that is clear (Fig 5.5). The page automatically generates a Latin Nn glyph in the top left of the page, instead of a more representative Hangul character sample. If I based my multiscript font choices on my initial reactions to that page, my pairings wouldn’t accurately capture the history and design of each typeface.

Visual density

CSS can help you control visual density—how much text, image, and other content there is relative to the negative space on your page. As you read on, keep cultural variables in mind: different cultures value different levels of visual density.

Let’s compare what are commonly called CJK (Chinese, Japanese, Korean) alphabets and Latin (English, French, Italian, etc.) alphabets. CJK alphabets have more complex characters, with shapes that are generally squarer than Latin letterforms. The glyphs also tend to be more detailed than Latin ones, resulting in a higher visual density.

Your instinct might be to create custom type sizes and line heights for each of your localized pages. That is a perfectly acceptable option, and if you are a typophile, it may drive you crazy not to do it. But I’m here to tell you that­ when adding CJK languages to a design system, you can update it to account for their visual density without ripping out a lot of your original CSS:

1. Choose a font size that is slightly larger for CJK characters, because of their density.
2. Choose a line height that gives you ample vertical space between each line of text (referred to as line-height in CSS).
3. Look at your Latin text in the same sizes and see if it still works.
4. Tweak them together to find a size that works well with both scripts.

The 2017 site for Typojanchi, the Korean Typography Biennale, follows this methodology (Fig 5.6). Both the English and Korean texts have a font-size of 1.25em, and a line-height of 1.5. The result? The English text takes up more space vertically, and the block of Korean text is visually denser, but both are readable and sit comfortably within the overall page design. It is useful to compare translated websites like this to see how CSS styling can be standardized across Latin and CJK pages.

Text expansion factors

Expansion factors calculate how long strings of text will be in different languages. They use either a decimal (1.8) or a percentage (180%) to calculate the length of a text string in English versus a different language. Of course, letter-spacing depends on the actual word or phrase, but think of them as a very rough way to anticipate space for text when it gets translated.

Using expansion factors is best when planning for microcopy, calls to action, and menus, rather than long-form content like articles or blog posts that can freely expand down the page. The Salesforce Lightning Design System offers a detailed expansion-factor table to help designers roughly calculate space requirements for other languages in a UI (Fig 5.7).

But wait! Like everything in cross-cultural design, nothing is ever that simple. Japanese, for example, has three scripts: Kanji, for characters of Chinese origin, hiragana, for words and sounds that are not represented in kanji, and katakana, for words borrowed from other languages.

The follow button is a core part of the Twitter experience. It has six characters in English (“Follow”) and four in Japanese (フォロー), but the Japanese version is twenty percent longer because it is in katakana, and those characters take up more space than kanji (Fig 5.8). Expansion tables can struggle to accommodate the complex diversity of human scripts and languages, so don’t look to them as a one-stop or infallible solution.

Here are a few things you can do keep expansion factors in mind as you design:

• Generate dummy text in different languages for your design comps. Of course, you should make sure your text doesn’t contain any unintentional swearwords or improper language, but tools like Foreign Ipsum are a good place to start getting your head around expansion factors (http://bkaprt.com/ccd/05-13/).
• Leave extra space around buttons, menu items, and other microcopy. As well as being general good practice in responsive design, this allows you to account for how text in your target languages expands.
• Make sure your components are expandable. Stay away from assigning a fixed width to your UI elements unless it’s unavoidable.
• Let longer text strings wrap to a second line. Just ensure that text is aligned correctly and is easy to scan.

For a happy pregnancy: Coimbatore Parenting Network rings in Mother’s Day with a two-day online session on pregnancy, raising babies, and making informed birthing choices

‘Sports without fans possible but magic will be missing’

Meghalaya’s lone COVID-19 patient tests positive again

Chamling hits out at Sikkim Govt

Tripura COVID-19 scene worsens as 24 more BSF jawans test positive

Man from Lanka tests COVID-19 positive in Dubai

Massive protest against killing at Harangajao

Cancer grid project crawls as key professionals exit entity

'Death Cap' mushrooms behind death of six in Meghalaya

Washington, DC : American Chemical Society, [2018]

New York : Springer, [2006]

Incarnational preaching and connection creates a stronger community.

Six flights flew in from five countries on Friday. Passengers returned from Singapore, Dhaka, Bahrain, Riyadh and Dubai to Delhi, Srinagar, Kochi, Kozhikode and Chennai

Union Home Minister met the Directors-General of all CAPF and directed proper arrangements for health check-up and treatment of ‘COVID warriors’

Six of them are in Delhi and 24 others in Tripura

Gilead Sciences Inc said on Tuesday it was in discussions with chemical and drug manufacturers to produce its experimental COVID-19 drug remdesivir for Europe, Asia and the developing world through at least 2022.

Tesla chief Elon Musk said that he was "selling almost all physical possessions" and would no longer own a home and would devote himself to Mars and Earth.

Nearly 3.2 million laid-off workers applied for unemployment benefits last week as the business shutdowns caused by the viral outbreak deepened the worst US economic catastrophe in decades. Roughly 33.5 million people have now filed for jobless aid in the seven weeks since the coronavirus forced companies to close their doors and slash their workforces.

Mobile phone applications that trace the new coronavirus could help decide whether business travelers and vacation-goers get to meet clients or visit their favorite beaches this summer. But politics and disagreement over what system to use threatens to thwart that solution.

Classicists help connect our lives to those of the ancient world, but in Suzanne Lye's course on magic and religion, her students do more than just connect — they create. And they learn to relate to the everyday problems and spellbinding solutions of ancient peoples.

One of the objectives of a value-added tax system is to simplify the administration of taxes, and this is accomplished by taxing almost everything and everyone, but allowing input tax credits (ITCs) for those who are not considered to be the final consumer of supplies. While many accounting and finance professionals understand the basic rules for claiming ITCs for GST/HST paid on property and services acquired in relation to an organization’s commercial activities, few have the time to explore some of the more complex issues associated with ITCs.  

Available Sessions for this Seminar:

March 04, 2015 12:00 PM - 2:00 PM EST

According to Central Silk Board statistics, West Bengal and Assam contribute around 6.5 thousand Metric Ton (MT)silk to India's total annual output of over 35,000MT. Over 80% of that is consumed in domestic market. As estimated, over 15 lakh workers are involved in ground level silk activities in these two states.

Online Resource

Online Resource

Online Resource

Online Resource

Online Resource

Online Resource

Online Resource

Online Resource

Online Resource