Tag Archives: Accessibility

The Fall Creators Update Brings Us Closer to a Windows for Everyone

By Jenny Lay-Flurrie, Chief Accessibility Officer

Today, with the launch of the Windows 10 Fall Creators Update, Microsoft is taking a big step forward on our journey to make our products more accessible and empower people with disabilities. Our teams have been working tirelessly to build inclusive content and expand the usability of core accessible features. The Windows 10 Fall Creators Update delivers a ton of new features and experiences, some of which are mind blowing! But of course, I’m most excited by the updates, improvements and new tools for people with disabilities, and I want to share a few of my favourites with you.

First, let’s talk Eye Control. The Windows 10 Fall Creators Update will deliver a beta version of Eye Control, which empowers people with disabilities to use a compatible eye tracker, such as a Tobii Eye Tracker, to operate an on-screen mouse, keyboard and text-to-speech experience in Windows 10 using only their eyes. Eye Control began as a hack project during our One Week Hackathon, turned into a Microsoft Research project and ultimately became a product concept in the Windows team. It is an early feature set so we are really keen to hear from you as we continue to work on this input vehicle. So please, check it out and continue to share your feedback!

[embedded content]

An audio description of the video is also available.

We’ve also made updates to some products you may know and recognize that are already part of Windows 10. That includes new Learning Tools (also, originally a Hackathon project) capabilities in Microsoft Edge. Learning Tools are a set of features that make it easier for people with learning differences like dyslexia to read. In this update, we’ve added the ability to simultaneously highlight and listen to text in web pages and PDF documents to make it easier to read. These new solutions also make it easier not just for English language learners and people with dyslexia, but for everyone, to increase their focus, to improve their comprehension and to reduce their error rate when reading.

Another is Dictation on the Desktop. Already, this feature allowed people with vision, mobility and cognitive disabilities to speak into the microphone, and convert that using Windows Speech Recognition into text that appears on screen. In the Windows 10 Fall Creators Update, you can now use dictation to input English text on the desktop. Besides dictating text, you can also use voice commands to do basic editing or to input punctuation.

It’s not just about productivity at work in the Windows 10 Fall Creators Update – we want to make sure the time you spend online for fun is just as accessible and inclusive! We added a feature to our screen reader in Narrator that uses Microsoft Cognitive Services to generate image descriptions for pictures that lack alternative text. For websites or apps that don’t have alt-text built in, this feature will provide quick and accurate descriptions of an image. We also listened to your feedback and made it possible to use Magnifier with Narrator, so you can zoom in on text and have it read aloud.

Another one of my absolute favourite developments is a new feature for people with colour blindness, which affects approximately 1 in 12 men and 1 in 200 women around the world. Color Filters are designed to improve the usability for people with colour blindness so they can more easily differentiate between colours like red and green. Consuming content is easier and since this feature works at the system level, all installed software and third-party apps will follow the filter you set up. Color Filters are available in greyscale, invert, greyscale inverted, Deuteranopia, Protanopia or Tritanopia.

There is so much goodness to digest in this update and we’re definitely excited about it. I’m thrilled at how far we’ve come since the initial launch of Windows 10, including enhancements with the Windows 10 Creators Update. At that time, we promised to invest in updates to improve the user experience for people with disabilities and I hope you’re seeing the progress. In July 2016, we shared the offer to extend the free Windows 10 upgrade. This extended availability is now coming to a close, as we’ll wrap this offer at the end of 2017. Please take advantage of this offer before it is retired at the end of this year!

It’s an exciting day for Windows users, and we hope that you’ll try out the new features and provide your feedback. This is how we make our products better and we want to learn from you. Don’t forget, if you are a customer with a disability (of any kind) and need technical assistance, the Disability Answer Desk is there to assist via phone, chat and in the United States, we also have an ASL option for our customers in the Deaf and hard-of-hearing community (503-427-1234).

Go create!

Working Together to Advance Disability Inclusion in the Business Community

By Jenny Lay-Flurrie, Chief Accessibility Officer

We recently attended the 20th Annual U.S. Business Leadership Network (USBLN) National Conference in Orlando. It was truly an amazing week with over 1,200 people from across the U.S. corporate sector coming together to empower the business community to create inclusive workplaces that value people with disabilities. This year, Microsoft had an especially strong presence with 25 folks representing the company, speaking in panels (including a new technology track) and interviewing prospective employees with disabilities. So many moments of inspiration and I want to share a few nuggets of joy, many of which reflect the progress we’ve made in our accessibility journey here at Microsoft.

Microsoft employees gather on stage at USBLN conference to accept an award

Members of the Microsoft Accessibility Team receive the Marketplace Leadership Award in the Product Design Category!

This was my 7th USBLN, and each year we increase our knowledge in this space, learning from peers across industries while sharing our own journey. As we shared recently, the USBLN Disability Equality Index (DEI) has taught us a great deal about disability inclusion and it was humbling to receive a perfect score on the DEI this year and be one of the 2017 Disability Equality Index (DEI) Best Places to Work! I’m so proud to see the wonderful progress we’ve made and even more excited to see what else we can do to make Microsoft an even more inclusive place to work.

While we’re humbled to receive this recognition, creating an inclusive environment that attracts diverse talent isn’t something we do just for the heck of it – we do it because it makes business sense. Without diverse talent, we couldn’t build products that work for everyone and that’s critical to achieving our mission. We continue to seek out great talent, so please take a look at our Inclusive Hiring Site, which includes all of our open roles focused on accessibility as well as provides more information about Microsoft’s inclusive hiring efforts. In that spirit do check out four videos we released during the USBLN conference that follow the personal journeys of several amazing Microsoft employees: Amos Miller, Jessica Rafuse, Joey Chemis, and Swetha Machanavajhala. They represent the kind of diverse talent that every organization needs to succeed in a global marketplace.

What’s most exciting is seeing what can come of hiring diverse talent and what a passionate group of people can accomplish. As part of each year’s conference, USBLN presents several leadership awards to recognize leading disability workplace, supply chain, and marketplace practices. I’m incredibly excited to announce that Microsoft was given the Marketplace Leadership Award in the Product Design Category. This award represents work from across the company, including Narrator updates, Braille support, Accessibility Checker, which now sits right next to spell check across Office 365 products, new features like Presentation Translator (real time captioning!), and PowerPoint Designer which gives the ability to create beautiful slides with literally a couple of clicks. While I’m so very proud of the work so far, and the milestone it represents on our accessibility journey, we are not done! The list is long and we look forward to launching more features and experiences in the near future.

I came away from this year’s conference humbled by the amount of work accomplished by so many to drive disability inclusion across industries and the incredible commitment demonstrated to continue that journey. The technical track was deemed a great success and we’ll be working to bring more of the same next year!

I put a challenge out there in the opening session to see what we can do to change an unemployment rate that hasn’t materially shifted in nearly 30 years. With the power in the room, anything is possible. So please, if you haven’t gotten involved with USBLN, do reach out. Use the DEI to grow wisdom and build your journey to disability inclusion.

Lastly, on behalf of the entire Microsoft team, thank you USBLN team for hosting such an incredible event. Can’t wait for next year!

Announcing the winners of the 2016 10k Apart contest

When we announced the 10k Apart contest back in August, we thought we might get a hundred entries or so. Sure, there was a lot on the line in terms of cash and prizes, but we had no idea that we’d be inundated with entries. We received over 380 entries for the contest—147 on the final day—and accepted over 270 of them into the gallery. Then the judging began and, after a lot of deliberation, our esteemed panel of judges has picked our winners.

The Honorable Mentions

We had so many amazing entries this year that I was glad we’d doubled the honorable mention spots. Without further ado, the honorable mentions for this year’s contest were (in alphabetical order):

Such an amazing group of entries! I highly recommend you check each one out. Do yourself a favor and set aside a few hours to really tuck into them.

People’s Choice: Firstname Basher

Once the entries were up, we gave you the chance to have your say and pick our People’s Choice award winner and you picked a cheeky little entry by Emilien Schneider, Pablo Barral, and Romain Petiot called Firstname Basher. This clever site helps you pick a name for your child, not by telling you its good qualities, but by telling you what’s wrong with it!

Screen capture of the Firstname Basher entry

Firstname Basher by Emilien Schneider, Pablo Barral, and Romain Petiot

Best Technical: 10K UK Weather Analyzer & Visualizer

This was a hard-fought contest between a handful of stellar entries. Ultimately, 10K UK Weather Analyzer & Visualizer by Yash Raj Singh took home the prize. Judge Rachel Andrew had this to say about it: “I love the use of open data in this one and the various little touches to help bring that data to life, obviously a lot of careful work has gone into this entry.” Judge Heydon Pickering was equally impressed: “Incorporating several impressive features including data visualizations and a little meta game, this was perhaps the most ambitious entry.”

Screen capture of 10K UK Weather Analyzer & Visualizer

10K UK Weather Analyzer & Visualizer by Yash Raj Singh

Best Design: 10KB Pixel Art Character

This was another toughy. We got so many beautiful entries this year. Ultimately, Hannah Malcolm’s 10KB Pixel Art Character took home the prize. It’s a fun little app for building your own 8-bit avatar. Judge Lara Hogan had this to say: “Super cute and it seems tremendously extendable.” Well done!

Screen capture of 10KB Pixel Art Character

10KB Pixel Art Character by Hannah Malcolm

Best Overall: Dashingly Responsive

I think the judging panel was geeking out big time over the winning entry. Judge Rachel Andrew nailed it when she said “Each time I looked I saw another small detail that impressed me, and the use of simple technology in a creative way seemed to sum up the competition for me.” Mat Marquis felt much the same: “There are a lot of sharp little details in the design of this page, implemented well—and coming in at only ~8k in total, including audio, is pretty impressive stuff.” High praise for Emil Björklund and his deceptively simple-looking Dashingly Responsive. Under the hood it was anything but simple.

Dashingly Responsive supports a variety of screen sizes and even shrinks to morse code on incredibly narrow screens.

Believe me when I say you will want to take some time to dig into Emil’s code to really digest all of the magic he worked into such a small package. And he left lots of very helpful comments in the markup to let you know what he did and why he did it. It was cheeky, clever, and demonstrated a mastery of front-end design and development we should all aspire to.

Great work Emil and congratulations on your much-deserved win!

Thank you all so much for participating in this year’s 10k Apart contest. Whether you entered, voted, or simply cheered the entrants from the sidelines, your efforts have helped spark renewed interest in creating amazing experiences that are tiny, fast, and accessible to everyone. Let’s do it again soon!

Aaron Gustafson, Web Standards Advocate

Building in 10k: Designing for Optimization and Performance

Editor’s note: This is the third in a series of posts from the team that built the 10k Apart contest page, exploring the process of building for interoperability, accessibility, and progressive enhancement in less than 10kB.

In the previous post in this series, I talked a lot about how the 10k Apart contest began to take shape in terms of markup. While I was busy doing that, Stephanie Stimac was tucking into the project form the design end of things.

I’ll step back for a bit and let he talk about her process.

Where do I begin?

As I started poking through the wireframes and information architecture documents for the 10k Apart website, I realized I would have to approach this a little bit differently than other microsites I’ve designed in the past. I knew I needed to keeping the code light and avoid excessive use of unique margins, padding, fonts, and font sizes. I needed to identify the patterns in the wireframes and focus on creating shared properties where possible—font-family, font-size, margin, and padding. Consistency and repetition would be key in keeping the CSS as small as possible.

Incidentally, consistency is a key tenet of design, so we had some solid alignment there.

With this in mind I set about creating three “themes” in Illustrator, following the style tiles approach championed by Samantha Warren. I’ll circle back to the style tiles, but first I want to touch on a few other things that I was thinking about during the design process.

What can I do in terms of typography?

10kB is not a lot to work with when you start to think about fonts. Heck, most fonts clock in at double or triple that weight for a single face! Custom fonts were out the window. Instead, I focused on picking a pair of fonts—serif and sans-serif—that were web safe, were system fonts, or had a similar looking fallback font.

I considered Times New Roman—for a hot second—as the primary header and logotype font, but my personal aesthetic could not allow it. Georgia is thicker and softer around the edges. It sits a little more heavily on the page. But in the event Georgia isn’t available, falling back to Times New Roman wouldn’t be the worst thing in the world. We took it a but further though and came up with a well-supported font stack for all serif text:

font-family: Georgia, Times, "Times New Roman", serif;

For body copy and other content blocks longer than a headline, my original style tiles used Arial. It’s pretty universally supported (and almost equally despised). In the end, though, we realized we could offer something a little better to our readers and built a stack around Segoe UI. We still use Arial in the rather exhaustive fallback list though:

font-family: "Segoe UI", Frutiger, "Frutiger Linotype",
             "Dejavu Sans", "Helvetica Neue", Arial,

If you’re looking to use default fonts like this, CSS Font Stack is an incredibly useful resource. It contains information about availability on both Windows and Mac and offers suggestions for alternatives as well as font size recommendations.

Screen capture showing Font Stacks, with title and body text styles open in a selection of different fonts.

Can I compress colors?

Color was a little bit trickier to work with. The color scheme is limited to three main colors with either a shade or a tint of one of those as an alternative for hover events, so you know when you’ve hovered or clicked on an item. I chose a limited palette, again, in order to reduce the amount of code it would require to build.

Once I picked my colors, I took things a bit further—some might say too far ;-)—and tuned them to create hex codes that were either alternating characters (e.g., #232323) or that used only a three-character hex code (e.g., #ccc).

The light and dark greys were not a problem; they were easy to pick with alternating characters. The initial blue and orange swatches took more time to match up with a three-digit hex code. When I converted the six-digit code to a three-digit code, the color difference was sometimes staggering. So I went through and tweaked a few of my initial colors in order to get as close as possible to the ones I wanted.

Of course, through all of this I was checking my color contrast to ensure the design would not cause accessibility issues. This led to further color adjustments along the way. Our goal in terms of color contrast was WCAG Level AA and we were able to achieve that. Of course it helped that we used rather large fonts across the board—a font size equivalent of 20px was our baseline.

Screen capture of Lea Verou's Contrast Ratio checker, showing contrast ratio comparisons for different color pairs.

Lea Verou’s Contrast Ratio tool.

How many themes should I create?

Even with all of these constraints, I had a bunch of ideas for how the site could look. I ended up sharing three approaches with the team, using style tiles to convey how each would apply to the various patterns and components throughout the site. They all shared many characteristics, but with varying color palettes, different header designs, and slightly different typography (Georgia rather than Times New Roman, for instance). As I was very confident in the overall design of patterns like projects, forms, and such, color was the primary differentiator across the three themes.

The green monochromatic style was developed after looking at An Event Apart and the original 10k Apart website from 2010. The colors were mostly muted with the exception of the buttons, which were red to draw your eye. Ultimately this direction didn’t provide enough contrast between elements with the monochromatic scheme.

Using that as a baseline, I created an alternate approach with a more serious, rigid tone. This option provided more contrast between the green and gold. I brightened up the green because the muted green did not offer enough contrast with the gold. I also introduced a dark grey to help punch up the contrast between elements.

The third theme ditched the green completely. I have a hard time using green and red together without a design screaming Happy Holidays! and I also wanted this third approach to have a completely different tone than the other two. In the end, I opted for a palette based on orange and a blue. The inspiration for this palette came from the call-to-action buttons on An Event Apart’s website, which are a bright, vivid orange.

Screen capture showing the An Event Apart page with vivid orange call-to-action buttons.

I toned the orange down just a little bit and paired it with a blue that wasn’t too heavily saturated in order to balance the orange. The tone of the design changed completely—the orange immediately gave the design more energy. It made the whole design feel more creative and inviting. Ultimately, I think that’s why it was the direction we decided we should go.

We did end up using the header style from the monochromatic design in the end. Normally I don’t like to mix ideas from different designs, but without that big block of color at the top, the whole design felt lighter. It didn’t feel like a compromise… it just worked.

Screen capture showing the final style tile for 10K Apart

I’m normally a full page mock-up kind of designer, but I found that the style tiles worked really well. Perhaps it was because this was such a small site with only a handful of patterns, but they helped speed the visual design process along. And I was happy to see how well they translated into the final, realized design in code—after all, that’s where it really matters.

What about that hero illustration?

With the basic design handled (and Aaron busily implementing it), I turned my attention to the homepage hero. I knew I wanted the illustration to be a metaphor for the 10k Apart site and for the entries that would eventually be submitted to it. I also liked the old-time contraption design used in the 2010 edition of the contest.

Screen capture of the 10K Apart 2010 page, with a hero illustration of a pedal-powered flying machine.

After seeing her amazing talk on SVG animations at SmashingConf, we approached Sarah Drasner about getting involved with the illustration. After all, what could be cooler (or smaller) than an animated hero shot in SVG? She was enthusiastic about the contest, and the challenge of building something both really cool and really small, so we set to work.

After a brief chat, we were all loving the idea of something antique and interactive. And so Sarah went away for a few days and came back with an early version of the hero you see today. She even figured out how to get the size of the SVG under 10kB while still keeping it interactive and highly detailed. (Aaron will discuss how it’s lazy-loaded in a future post.)

Sarah nailed the concept of a vintage contraption that required a lot of machinations to pop out something simple. And that’s really what this process and this contest is all about: working hard, iterating and re-iterating until we come up with something small, simple, and amazing!

What did we learn?

Stephanie’s walkthrough covered a lot of territory, so here’s a little summary of the takeaways:

  • Consistency matters — not only are consistent designs more usable and cohesive, they’re also smaller;
  • Fonts can be a bandwidth hog — even single typefaces can be quite large, consider using web safe or standard system fonts;
  • “Web Safe” doesn’t have to be boring — just because you’re using a web safe font stack doesn’t mean you can’t get creative, you can even take things further by exploring larger font stacks with options that cater to the different platforms;
  • Colors can compress — repetitive hex values and hexidecimal shorthand can help make your CSS smaller;
  • Contrast is key — design is not painting a pretty picture, people need to use your work so make sure they can read it;
  • Design systems, not pages — style tiles are a great tool for exploring design themes and get you to think in terms of a design system rather than a collection of pages; and
  • SVG is amazing — it’s incredible how much you can do with SVg illustrations: they’re small, they scale, and they can even be animated.

Where to next?

With a beautiful and highly usable design direction in place, it’s time to write some CSS. Stay tuned!

Aaron Gustafson and Stephanie Stimac

Building in 10k: Markup for Accessibility, Clarity, and Affordance

Editor’s note: This is part two in a series of posts from the team that built the 10k Apart contest page, exploring the process of building for interoperability, accessibility, and progressive enhancement in less than 10kB.

In the previous post in this series, I talked a lot about how the 10k Apart contest site began to materialize in terms of structure and content. Once the planning was done, I was finally able to start building the site in earnest.

Where do I begin?

Generally, the first step I take in building any site is to drop some sample content into a fresh HTML document and then work my way through it, marking things up as I go. In the case of this project, I decided that sample content would be all of the patterns I had identified in the wireframes. It seemed like a solid starting point that would get me pretty far in terms of building out the bits I’d need to flesh out the full site.

First things first, I copied in the content from the wireframes. Then I began asking one simple question over and over: How can I use markup make this better?

The purpose of markup is to twofold:

  1. To give structure to a document; and
  2. To convey (and enhance) the meaning of the document’s content.

With that question in mind, I began to work my way, bit by bit, through the document, always on the lookout for opportunities to make it a little more meaningful, a little more usable. I was, of course, ever-mindful of that looming 10kB limit too. Markup tends to be pretty small, but I wanted to minimize cruft and focus on markup that actually added value to the document.

What’s the minimum viable structure?

Every page needs structure, so I started there. First off, I dropped in a minimal HTML5 shell:

.gist table { margin-bottom: 0; }

Have I told you how thankful I am for that simplified DOCTYPE? It’s worth noting that I added an id to html element to act as a site identifier. This is a practice I picked up years ago from Eric Meyer as a helpful option for folks who rely on user styles and want to override a specific site’s styles rather than every site’s.

With the minimal shell in place, I set to work marking up the content in my patterns document. I began by surveying the content and identifying key regions like the site banner, navigation, primary content, and footer. All of these pieces have semantic meaning and they also have associated HTML elements. Let’s step through them, one by one.

A “banner” is introductory content for a web page. ARIA granted us the ability to identify a site’s banner using role=”banner”, so it would be completely reasonable (and accessible) to mark up the site’s banner like this:

.gist table { margin-bottom: 0; }

Incidentally, HTML5 introduced the header element, which operated in a similar way. Semantically, it’s intended for introductory content. The header element can be used directly in the document body as well as within sectioning elements (like article and section). What’s really cool is that the first header encountered in the body (but not inside a sectioning element) is exposed to assistive technology as the site’s banner. That means we can skip adding the role and just do this:

.gist table { margin-bottom: 0; }

Why do we care about the semantic equivalence? Well, assistive technologies can use landmark roles like “banner” to enable a user to move around more quickly in a document.

The next thing I needed to address in the document was the navigation. There’s an ARIA role for that: role=”navigation”. However, there’s also a corresponding HTML5 tag: nav, which is a bit less verbose. Done and done. Well, almost. In order to identify the purpose of the navigation, I can enlist another ARIA property: aria-label:

.gist table { margin-bottom: 0; }

This ensures assistive technology exposes the purpose of the navigation to users. Edge with Narrator, for example will read out “Main Navigation, navigation, navigation landmark”.

NVDA with Firefox would read this out as “Main Navigation, navigation landmark.”

Next up is the primary content. ARIA denotes that with role="main", but the newer main element accomplishes the same thing more succinctly.

.gist table { margin-bottom: 0; }

Finally there’s the footer. HTML5 has the footer element which, like header, can operate in either a sectioning context or a page context. And like header, the first footer encountered in the body (again, provided it’s not a descendent of a sectioning element) will automatically be granted a semantic value equivalent to ARIA’s “contentinfo” role. That role denotes meta information about the content, like copyright. Just what we need!

Rolled all together, the document structure was simple and semantic, with nary a div in sight:

.gist table { margin-bottom: 0; }

Where can I provide more meaning?

With the basic document structure in place, I began to look at the individual patterns with an eye for where I could add value using markup. In many cases, simple tried and true elements like headings, paragraphs, and lists made the most sense. For example, the navigation is really a list of links. The order really doesn’t matter, so I used a ul:

.gist table { margin-bottom: 0; }

The cool thing about that approach is that when assistive technology encounters that navigation landmark, users get an even more useful information. So, going back to the NVDA example from earlier, this would be read as “Main Navigation, navigation landmark. List with three items.” That’s super helpful!

HTML’s native semantics can do a ton to super-charge our documents like this. Remember folks, not everything should be a div.

What needs to be identified?

The “common wisdom” within the web design world is to avoid using the id attribute. The oft-cited reason for this is that in a CSS selector, an id selector (e.g., #foo) carries a lot of weight in specificity calculation and often lead designers to create unnecessarily over-specific selectors. That is 100% true, but I think it gives id a bad rap. Modern attitudes toward id often remind me of the antagonism many of us felt for table when we were trying to get folks to move from table-based layouts to CSS. It took the best of us down some pretty weird rabbit holes. The table element is absolutely the best choice for marking up tabular content.

The id attribute is used to identify a specific element on the page. You can use it for CSS, sure, but it has other uses as well:

  1. It creates an anchor to that element in the document (try it out by adding “#comments” to the address bar of your browser);
  2. It creates a simple and inexpensive means of document traversal in JavaScript: document.getElementById();
  3. It creates a reference-able identifier useful for associating the identified element with another one via for, aria-labelledby, aria-describedby, and other attributes.

As with many things, id can certainly be overused, but that doesn’t mean you shouldn’t use it. In terms of the 10k Apart site, I opted to use it in the forms (which I will discuss shortly) and extensively on the FAQ page and the Official Rules page.

On both of those pages, I used id to create anchor points so I could point folks directly to certain sections. On the FAQ page, which is relatively long, I used short id values like “size”, “js” and “a11y” (short for “accessibility”). The Official Rules are a bit longer, so in order to save some bits, I opted to use the section character (“§”) as a prefix to the id values. If you look at the source of that page, you’ll see id values like “§–1”, “§–2”, and “§–3”. They may look weird, but they are valid id values.

What are the common patterns?

The id attribute is great for identifying specific elements, but there are lots of instances where elements share a function. One example of that is the gallery of projects and the gallery of judges. And so I chose to classify the two lists as being of an ilk, using a class of, you guessed it, “gallery”.

Another example of elements that are related are the various project instances. Each instance is a “project”, but a project has certain characteristics when it is part of a gallery and other characteristics when it’s on its own page. Each instance shares the class of “project” but can also receives a modifier class to denote its context. I chose to follow the BEM syntax for classifying elements, but there numerous other ways to accomplish the same goal. Here’s what I came up with:

  • .project — Used for all projects;
  • .project--page — Used for the project on its own page;
  • .project--hero — Used for the Grand Prize winner in the final version of the homepage;
  • .project--winner — Used for projects that have won a prize; and
  • .project--preview — Used for the JavaScript-based live preview accompanying the entry form.

Since I’m on the subject, I also used the BEM approach to keep my styles modular. Continuing with the project example, a project instance could have multiple properties associated with it:

  • .project__author — The person who submitted the project;
  • .project__name — The name they gave the project; and
  • .project__won — The prize a project won

Doing this allowed me to isolate project-related styles to specific elements based solely on their purpose, rather than the markup they happened to use (which might change from instance to instance, depending on the needs of the page).

How can I make the forms better?

Content, the official rules, and the projects themselves are all obviously quite important to this site, but without a usable entry form, the whole project is kinda pointless. Part of making more usable forms for the site started with the planning and began with eliminating unnecessary fields. That removed a lot of the noise from the entry form. The next step was humanizing the language, which I mentioned in the last post. Practically, it meant moving away from terse and rather useless labels like “Name” toward more conversational labels that actually beg a response, like “What’s your name?”.

With solid, conversational labels in place, I then went about associating them with the various form controls. To start with, I marked all of the standard fields up as input elements with no type assignment (meaning they all defaulted to “text”). I then marked up each bit of label text in a label element and then tied the two together using a for attribute on the label that referenced the id attribute of the associated field. I did the same with the select, textarea, and checkbox controls. Here’s an example:

.gist table { margin-bottom: 0; }

I opted to use single character id values to save room so I could spend additional markup characters on additional enhancements.

Next, I went through the form and looked for fields that were asking for specific kinds of structured information, like an email address or a URL. When that was the case, I used the corresponding input type. Here’s an early instance of the email field, for example:

.gist table { margin-bottom: 0; }

My next pass added attributes to signify if a field was required. To get the greatest amount of coverage in this area, I doubled up the required attribute with aria-required="true". It’s redundant, but not all assistive tech/browser combinations treat them as equivalent… yet.

.gist table { margin-bottom: 0; }

I used the next pass to control how content could be entered into the fields in order to provide a better experience for folks in browsers that support autocorrection, automatic capitalization, and the like. (If you’re interested, there’s a great overview of best practices for streamlining data entry, especially on mobile.) For the “name” field, that meant turning off autocorrect and setting it to autocapitalize words.

.gist table { margin-bottom: 0; }

Then I went through and provided some silly placeholders to suggest the kind of content a user should be entering into the field.

.gist table { margin-bottom: 0; }

And my final pass added support for auto-complete, which enables users of supporting browsers to fill out the form even more quickly by identifying the specific information the browser should supply for each field.

.gist table { margin-bottom: 0; }

If you’re intrigued by this idea and want to know more, you should definitely read Jason Grisby’s treatise on autocomplete.

It may not seem like much in the grand scheme of things, but those minor markup tweaks add so much to the experience. And if a particular browser or browser/assistive tech combo doesn’t support a feature, no big deal. An input can be as simple as a text input and it’s ok. We’re still doing server-side validation, so it’s not like users who can’t take advantage of these enhancements will be left out in the cold.

And speaking of server-side validation, I should probably spend a few minutes talking about how that factors into the markup.

What if the form has an error?

Let’s say you forget to enter your name for some reason and your browser doesn’t pay attention to the HTML5 field types and attributes. The server will catch the error and return you to the form with all of the info you entered intact. It also summarizes the errors and provides some useful messaging about the error and how to fix it or why it’s important.

First off, a summary of errors will appear at the top of the form:

.gist table { margin-bottom: 0; }

Here we have an introductory message followed by a list of errors. Each error contains a link that anchors you directly to the corresponding field. (Yay id!) The whole message also has an ARIA role of “alert” indicating users of assistive tech should be informed of this content immediately after the page loads. A tabindex of 0 is also added to ensure it receives focus so the contents are read.

Drilling down to the field itself, we have the label, the field, and the error message. The label and the field are already associated (via the forid connection I covered earlier), but I needed to associate the error now too. In order to do that, I used aria-describedby which also makes use of id.

.gist table { margin-bottom: 0; }

In this case aria-describedby points to a single element (strong#e-n), but the attribute can actually reference multiple id values, separated by spaces. It’s worth noting I’ve also marked the field as invalid for assistive tech using aria-invalid="true".

Again, a teensy-tiny tweak to the markup that pays huge dividends in terms of usability.

Oh yeah, and one last thing: the form works perfectly in Lynx.

Screen capture showing the 10K Apart contest form in the Lynx web browser

What did we learn?

I covered a ton of stuff in this piece, so here’s a little summary of takeaways if you’re a fan of that sort of thing:

  • Markup for structure and semantics — Choose your HTML elements with purpose;
  • Labeling elements reduces ambiguity — aria-label can (and should) be your friend;
  • Don’t shy away from id — You don’t have to use it in your CSS, id has a bunch of other uses;
  • Classify similar elements — that’s what the class attribute is for, the naming approach is up to you;
  • Associate form labels with controls — no excuses… just do it;
  • Use the right field type — HTML5 offers a bunch of options, get familiar with them;
  • Indicate required fields — do it in your content and in your form controls;
  • Manage autocorrection and capitalization — your virtual keyboard users will thank you;
  • Suggest possible responses — but keep in mind the placeholder attribute is a suggestion, not a label;
  • Facilitate auto-completion — again, your users will thank you; and
  • Handle errors well — make it easy for users to find and correct errors.

Where to next?

With a solid set of markup patterns in place, I built out the site in earnest, following along with the wireframes. Once that was done, the next step was to design the thing. Well, technically some of the design had already begun while I was working on markup, but you know what I mean. Designer Stephanie Stimac will be joining me to talk about that process in the next post. Stay tuned!

Aaron Gustafson, Web Standards Advocate

Building in 10k: Content and Strategy

Editor’s note: This is the first in a series of posts from the team that built the 10k Apart contest page, exploring the process of building for interoperability, accessibility, and progressive enhancement in less than 10kB.

When Jeffrey Zeldman first approached me about bringing back the 10k Apart contest, my mind began to race. I’d been a judge on the 2011 incarnation of the contest, so I had seen it from that angle before, but he presented me with an amazing opportunity… not just bring it back, but to evolve it into the 10k Apart contest our industry so desperately needs today.

The 10k Apart (and the 5k before it) have never operated in a vacuum. They’ve always taken the pulse of industry trends and and then challenged us to do more, to do better, and with less. In 2010, the contest pushed us to embrace HTML5. In 2011, we were challenged to make our work responsive. And so I began to ask myself: what are the challenges we, as an industry, are struggling with today. Anyone who has followed my work could probably have guessed my answer: progressive enhancement.

And so I put together a list of changes to the contest that would help us move away from the very JavaScript-heavy entries I’d judged last time toward entries that would be usable by anyone. Entries that respected low-bandwidth connections, were considerate of users who rely on assistive technology, and embraced the inherent flexibility and malleability of the Web. And, of course, entries that broke the stereotype of progressively-enhanced projects being “boring”.

I was so excited when Jeffrey and Eric Meyer responded to my suggestions with overwhelming enthusiasm. Their encouragement challenged me to think about the rules I’d drafted to govern the contest and inspired me to make the contest site abide by those very same rules as a way of demonstrating how progressive enhancement can enable our web projects to do so much more. It’s not a yoke, holding us back; it’s a powerful philosophy that challenges us to look at experience as a continuum and pushes us to think outside of our comfortable high-tech bubble.

This is the first in a series of posts about the process of building the 2016 10k Apart contest site. I, and the wonderful team that helped me make it a realty, wanted to share what we did, but moreover why we did it. We’ll talk about the sacrifices we made in designing and building the site as well as the ways markup, style, and script took a simple transactional site and gave it the polish it so richly deserved.

Thanks for joining us on this journey…

What are you here to do?

Before tucking into code, information architecture, or even copy, I took some time to stroll through previous incarnations of the contest. I poured over the structure of the sites and examined the tone of voice they used, of course, but I also took the time to examine the purpose of every page. Who were the different audiences coming to the sites? What did they want to do? Did their goals change over time?

Asking all of these questions helped me to break the site’s audience into two main camps: Folks interested in entering the contest and folks interested in spectating. I also recognized that the motivations and goals of these groups would change as the contest progressed. Folks who entered might become spectators once they’d submitted their entry. Some spectators might be inspired to enter the contest themselves after seeing someone else’s project. And so I set about organizing the site to not only support these different, potentially overlapping audiences, but to make it easy to transition back and forth between them.

To accomplish this, the site would need to evolve with our audience through several phases:

  1. Launch – When we don’t have any entries (which is what is live as I am writing this);
  2. In progress – When we have entries that we want to show off, but the contest is still open (this phase will be kicking in soon);
  3. Close – When the contest is over and we aren’t accepting new entries, but instead focus on highlighting the folks that entered and ask you to vote for your favorites; and
  4. Winner announcement – When we celebrate the awesome works judged by our expert panel and you, the community, to be the best of the best.

With that outline in place, I began putting together lists of the sorts of content we would need on each page in each phase of the contest. I was ruthless in stripping away the cruft and the nice to have bits. In many ways, I followed the model Luke Wroblewski wrote about in Mobile First, by focusing on the core purpose of each page. I got rid of any bit of content or UI was a distraction from that purpose or that simply failed to propel people toward accomplishing their goal on that page. Each page, each step in the process, was ruthlessly stripped to its essence. And then the real work began.

How do we talk to one another?

Steph Hay is often quick to point out that every interface is a conversation we’re having with out users. With that in mind, I set about authoring copy that embodied that idea. I wanted your experience of the site to be just like sitting down next to me and talking about the contest.

In their book Nicely Said, Kate Kiefer Lee and Nicole Fenton offer a ridiculous amount of great advice on not just how to write, but how to write for people. In it, they talk about writing like you speak and even go so far as to recommend you read your work aloud. Looking to the future of “headless” UIs—Cortana, Alexa, Siri—and the current crop of screen reading options out there, it was pretty obvious that this was not only good advice… it was beta testing!

I applied the wisdom I learned from these amazing content strategists (and no doubt countless others) to everything from the page titles and body copy all the way down to form labels and error messaging. I read the content aloud and in many cases had my computer read it to me as well. I know there’s room for improvement (there always is), but I’m pretty happy with the way it turned out.

Where are the patterns?

Once I had drafted copy for each page in the site, I began to organize the content into basic wireframes. In the interest of time, I focused on wireframes for large-screen views of each page, making note of the content priorities so I would know how to arrange things on smaller screens as well.

Example wireframe from https://a-k-apart.com

While working on the wireframes, I made notes (some mental, some in the wireframes themselves) about where we could shave off some page size or where certain content was helpful, but more of an enhancement than core to the purpose of the page. I also looked for places where we could use markup or style to improve the experience greatly for very little cost. HTML5 input types, for example.

For more complicated interactions, I used Interface Experience Maps (IxMaps, which are effectively flowcharts) to outline the different ways users might be able to experience an interface. For example, on an entry page the most important information is the name of the project, the name of the person (or people) who made it, the description of the project, and a link to view it live. A screenshot, while helpful, is unnecessary. So I used an IxMap to explore lazy loading the screenshots only when JavaScript was available.

IxMap exploration of lazy loading screenshots when JavaScript is available. This IxMap depicts lazy loading a picture element and supplying alternate image formats for browsers that support WebP.

In that exploration, it dawned on me that I didn’t have to settle for only one image format—I could lazy load a picture element and supply alternate image formats for browsers that support WebP (which tends to be much smaller than JPGs and PNGs). That’s one of the reasons I love IxMaps: they allow for low-cost exploration and discoveries like this.

Once the wireframes and IxMaps were complete, I went through them and teased out repeating patterns and unique components, copying them to a new page in the wireframe document. In doing so, I also found opportunities to reuse enhancements I’d come up with for specific page components. Taken together, this pattern guide have our designer, Stephanie Stimac, a good overview of the site’s overall UI needs. It helped her avoid the trap of designing pages and let her create a design system instead. Stephanie will join me to talk about the design process in the third installment of this series.

What did we learn?

They may seem obvious, but in case you’re a fan of takeaways, here are a few relating to content, strategy, and information architecture:

  • Minimize distractions – Focus on the core purpose of every page, get rid of anything that is not supportive or detracts from that;
  • Write like you speak — Write for people like you would speak to them in person and read your work aloud;
  • Set content priorities — Ensure the flow is right and leads your users where they want (or need) to go;
  • Look for opportunities to enhance — Some supportive content may be nice to have but non-essential, consider removing it by default and bringing it back in certain scenarios; and
  • Look for patterns — Focus on creating a design system rather than individual pages.

Where to next?

With a good set of bones in place, the next step for me was to tuck into the markup, but that’s the story for another post. Stay tuned!

Aaron Gustafson, Web Standards Advocate

What would you do with 10kB?

Sixteen years ago, Stewart Butterfield conceived of a contest that would test the mettle of any web designer: The 5k. The idea was that entrants would build an entire site in 5kb of code or less. Its aim was to force us to get creative by putting a bounding box on what we could do:

Between servers and bandwidth, clients and users, HTML and the DOM, browsers and platforms, our conscience and our ego, we’re left in a very small space to find highly optimal solutions. Since the space we have to explore is so small, we have to look harder, get more creative; and that’s what makes it all interesting.

The 5k contest ran from 2000 until 2002. In 2010, An Event Apart and Microsoft revived the idea with an updated limit and a new name: 10k Apart. Staying true to its roots, this new incarnation, which ran for two years, continued to push designers and developers to get creative within a pretty extreme (though slightly expanded) limit while incorporating new goodies like HTML5 and responsive design.

Today we’re thrilled to announce that the 10k Apart contest is back and brings with it a handful of new challenges:

  1. Each page must be usable in 10kB or less. The 10kB limit no longer applies to the size of a ZIP archive of your entry; the 10kB limit now applies to the total initial download size of the baseline experience of each page in your project. When we say “baseline experience,” we’re talking small screen devices running older, less capable browsers. The 10kB limit will apply to every page and whatever assets it loads by default; that means images, CSS, JavaScript, and so on.
  2. Progressive enhancement is the name of the game. Your project should start with a super-basic, bare-bones-but-usable experience that will work no matter what (including without JavaScript). You can use clever CSS and JavaScript techniques to enhance that experience as it makes sense to do so. For example: You might lazy load an image using JavaScript if the screen size is above a certain threshold or when certain other conditions are met. Entries that depend entirely on JavaScript to render the front-end won’t be accepted. If you need a primer on progressive enhancement, consult the pages of A List Apart.
  3. Back ends are in this year. In previous iterations, each entry comprised client-side code submitted via ZIP file. Over time, that limitation led to an over-reliance on JavaScript for rendering. No more. This year, you can create dynamic experiences that work without front-end JavaScript using Node, PHP, Python or .Net. You will submit your entry as public GitHub repository (so we can all learn from your awesome code) and we’ll spin up a dedicated Azure instance running the appropriate stack.
  4. Entries should be accessible. In line with the philosophy of progressive enhancement, your entry should be usable by the broadest number of users possible. Accessibility is not a checklist, but if you’re clueless about where to start, these techniques can offer some guidance.
  5. Nothing comes for free. In previous years, we gave a pass if you wanted to use jQuery or load some fonts from Typekit. This year we decided to change it up, not because we don’t love these products (we do), but because we wanted to force every piece of code, every asset, to fight for its place in your entry. Anything you add should be added with purpose.

As with previous editions, your entry should use web standards and work in all modern browsers. You can use HTML, CSS, and JavaScript features and APIs that don’t have across-the-board support as long as you do so in keeping with the progressive enhancement philosophy. In other words, your entry can’t depend on that technology or feature in order to be usable.

All of this may sound like a tall order, but it’s entirely possible. In fact, the site we built for the contest also abides by these rules. We’ll touch on some of the techniques we used (and concessions we made) in building the site in future posts.

If you’ve read this far, you might be wondering What’s in it for me? Well, bragging rights, of course, but we’ve got some awesome prizes too! We’re giving away $10,000 to the top three entries, plus tickets to An Event Apart, complete collections of A Book Apart titles, and copies of my book too. Complete details of the prizes are over on the contest site.

We’ve lined up an amazing group to judge the entires this year too: Rachel Andrew, Lara Hogan, Mat Marquis, Heydon Pickering, Jen Simmons, and Sara Soueidan will all be putting your entry through its paces and peering under the hood at your code. There’s also a People’s Choice award which will be based on votes you cast. Voting will open September 5th and run through October 14th.

The contest opens today and we will accept entries until 5pm Pacific Time on September 30th. Everything you should need to know about the contest, eligibility, etc. is up on the 10k Apart site, but if you have additional questions, you can always reach out.

We can’t wait to see what you come up with! Happy coding!

Aaron Gustafson, Web Standards Advocate

Adding color to your design


What is your favorite color? Most of us have been asked this question for as long as we can remember. And for most of us, this decision probably marked our first and foundational experience with having an artistic preference.

Color matters. Previous posts have touched briefly on topics that have an artistic and a scientific side, such as typography and iconography. But whereas the effects of typography and iconography are subtle, the colors in your app have an immediate, emotional impact on your users.

Today’s post will deal with this emotional element of color in UX design, general rules of thumb for combining color, accessibility issues to consider, and finally, tips for finding the right colors to suit your specific app.

Color and emotion

Colors have an instantaneous effect on the brain and human emotion. Green rooms tend to make people feel calmer while red has been shown to enhance physical reactions. Although the influence of specific colors tends to vary depending on context as well as cultural background, the anecdotal evidence that certain colors can be used to influence people has been convincing enough that advertisers and product companies take color very seriously.

Here are some color attributes you should be familiar with:

  • Red is a vibrant and activating color associated with passion and danger.
  • Orange evokes nature as well as energy.
  • Yellow projects joy, intelligence, and positivity.
  • Green suggests renewal and is often found in financial apps.
  • Brown is natural and organic and can often serve as a good contrast for more vibrant colors.
  • Blue is often used to project calmness, security, and professionalism.
  • Violet evokes royalty and luxury.

These attributes should be taken as guidelines only. The meaning of a color can shift dramatically depending on the other colors combined with it and the context and imagery it’s associated with in your app. If you are interested in a deeper dive into the relationship between color and emotions, you may want to explore the Color In Motion website.

Color theory

Isaac Newton came up with modern color theory and even created the modern color wheel. You probably discovered color theory on your own, though, using finger paints and crayons. There are three primary colors: red, green, and blue. By combining these in an additive system, we can get three secondary colors:

  • red + blue = violet
  • green + blue = cyan
  • red + green = yellow


When you combine all these colors in an additive system, you get white (left). In a subtractive color model, like finger painting, mixing all your colors gives you black (right).


Colors can be placed on a wheel, as Newton did, with the secondary colors placed between the primary colors. This is a natural way to position colors and highlights some interesting relationships:

  • Complementary colors (a). Colors that are directly opposite each other on the color wheel.
  • Analogous colors (b). Colors on either side of a given color on the wheel.
  • Split complementary colors (c). Colors that are the analogous colors of a complementary color.
  • Triad colors (d). A set of three colors that are equally spaced apart on the wheel, each 120 degrees from the others.


Colors are also divided into warm and cool tones. The distinction between warm and cool colors is related to the anecdotal effects of color on the emotions discussed above. The warm colors extend from yellows at one end to reds at the other. The cool tones are blues, greens, and violets. Colors such as black, white, and the grays are neither warm nor cool. Instead, they are known as neutral colors. The remaining shades—such as browns, tans, and pastels—are called near neutrals.

UWP color codes are based around the red, green, and blue (RBG) model of color creation—and so are computer screens, for that matter. Any color on the wheel can be derived from a value from 0-255 for each primary color component for a total of 16,777,216 colors.

Tip: Xbox knocks off the ends of the spectrum, supporting somewhat fewer color choices. HoloLens can’t use pitch black (0, 0, 0) because this represents transparency in Windows Holographic.


Because you will occasionally encounter it, you should also become familiar with the HSL system, which stands for hue, saturation, and lightness. It offers a different mathematical model for representing colors. HSL (as well as a variant called HSV) is popular with graphics programmers and is probably already known to you if you’ve ever used a color picker. A hue can be thought of as a pure color. Saturation is how intense the hue is. A lightness of 100% applied to a hue gives you white, whereas a 50% lightness gives you the pure hue.

Color contrast and accessibility

Contrast describes how far apart two colors appear to be. It is important for an app with text because a high contrast will make your app easier to read. It is also important for your visual hierarchy, since high contrast will more clearly differentiate different areas of your layout.


So far, contrast seems like just an aesthetic problem. Contrast becomes an accessibility problem, however, when your app is used by people with poor vision or by people who are color blind. Color vision deficiency affects 8 percent of men and 0.5 percent of women worldwide. Because of this, color contrast isn’t something you can ignore.


There are two ways to evaluate the color contrast in your app. One way is to desaturate your colors until they are effectively grayscale. If your text is still readable and your visual groupings are still clear, then your color contrast is effective. Alternatively, you can use a color contrast analysis tool, like this one on colorsontheweb.com, to plug in your color values and receive an immediate evaluation of your Universal Windows Platform (UWP) app’s visibility.

Color schemes

There’s a lot of background that goes into understanding color and using colors effectively. Fortunately, there’s a shortcut to all of this color stuff that you can start using right away. Adobe provides a free tool at https://color.adobe.com that will allow you to quickly pick a color scheme that you like.


This color app will let you select any of the color relationships discussed in the color theory section above to select your color scheme: triad, complementary, analogous, or split complementary. It will then give you the color values for this color scheme at the bottom as both RGB and HEX values, which you can then plug into your UWP app. All you need to do is start with a dominant theme color that will create the right emotional context for your app using the descriptions in the color and emotions section. You can also play around with the tool until you find a main color that appeals to you and reflects the purpose of your app.

Wrapping up

We each have an intuitive understanding of how colors affect us emotionally. The goal of this post has been to provide you with the confidence to trust your own instincts when it comes to hues. With the color concepts provided in this post, you as a developer are in a position to better understand why you prefer one set of colors over another and are well equipped to have informed discussions about color schemes based on color psychology, color theory and accessibility.

Download Visual Studio to get started.

Introducing the Speech Synthesis API in Microsoft Edge

Starting with the Windows 10 Anniversary Update, Microsoft Edge will support the Speech Synthesis APIs defined in the W3C Web Speech API Specification. These APIs allow websites to convert text to audible speech with customizable voice and language settings. With them, website developers can add and control text-to-speech features specific to their page content and design.

Speech Synthesis is useful whenever narration might be applied. Our implementation also supports Speech Synthesis Markup Language (SSML) Version 1.0 to provide further control over the speech output.

Speech Synthesis is enabled by default in Windows Insider Preview builds starting with EdgeHTML 14.14316 and above – try it out with our new Speech Synthesis Demo on Test Drive!

API Overview

The Web Speech API Specification defines a SpeechSynthesisUtterance interface that lets Javascript set speech text along with attributes that control the voice used and modify the language pronunciation, voice, volume, rate and pitch of the voice output. Other interfaces are defined that allow playback control and monitoring state of the synthesized speech.

Microsoft Edge implements these SpeechSynthesis interfaces:

  • SpeechSynthesis: Provides speech playback control and state
  • SpeechSynthesisUtterance: Controls speech content, voice and pronunciation
  • SpeechSynthesisEvent: Provides state information on the current utterance
  • SpeechSynthesisVoice: Sets speech service information

Our implementation of these Speech Synthesis APIs is based on the WinRT Windows.Media.SpeechSynthesis APIs. These directly support most of the W3C Speech Synthesis interfaces. There are a few SpeechSynthesis details that we don’t currently support this release, which we’re evaluating for future releases:

  • Playback pitch: Used to vary the voice pitch on playback.
  • onmark event: Used to indicate that a marked tag has been reached.
  • onboundary event: Used to signal boundaries of spoken words or sentences.

Speech Synthesis Demo

To illustrate these new speech features, we’ve published a Speech Synthesis Demo on Test Drive. This allows input of random text (try something really long) and exposes parameters like voice, language, rate and volume that allow tuning of the resulting speech.

The demo includes this sample code that uses SpeechSynthesisUtterance to take your selected text and speech settings, and use them to do a text to speech voice synthesis.

.gist table { margin-bottom: 0; }

This sample reads in data from the demo HTML, and then uses window.speechSynthesis.speak to start playback. It shows how simple it is to add basic speech synthesis features to your website.

Speech Synthesis Markup Language (SSML)

SSML allows speech voices and content to be expressed in XML, allowing direct control over a variety of speech characteristics. You can try this by pasting SSML derived text into the Speech Demo.

Here’s an example of JavaScript SSML from the W3C spec:

.gist table { margin-bottom: 0; }

If we concatenate the SSML content, we get:

.gist table { margin-bottom: 0; }

Copy and paste this into the Speech Synthesis Demo text box to see how the voice selections affect the synthesize output.


The language setting in our Test Drive demo will work with any installed voice language pack in Windows 10. By default, there will be a primary language installed for a system. Others need to be installed. Here’s how to add an input language to your PC:

  • Go to Settings > Time & language > Region & language.
  • Select Add a language.
  • Select the language you want to use from the list, then choose which region’s version you want to use. Your download will begin immediately.

Once installed, the language pack will be used to alter the pronunciation of foreign language text.

We’re excited to share this release of HTML5 speech capabilities in Microsoft Edge. We prioritized Speech Synthesis based on feedback from users and developers, and we look forward to refining our speech support in the future with speech synthesis feature enhancements and speech recognition capabilities.

Try it out and let us know what you think!

– Steve Becker, Senior Software Engineer
– Jerry Smith, Senior Program Manager