About the Author:

EASY Speech Recognition and Speech Synthesis in JavaScript

December 19th, 2016

As a society, we’ve become increasingly intrigued by the concept of machines that can talk and listen. From fictional AI systems like HAL 9000 in 2001: A Space Odyssey (“I’m sorry, Dave. I’m afraid I can’t do that.”), to Apple’s Siri ,and Google’s new Assistant, our culture seems inexorably drawn to the idea of digital beings with ears and a voice. Implementing such sophisticated technology may seem far beyond the grasp of a beginner or even more experienced programmer; however, that assumption couldn’t be further from the the truth. Thanks to user friendly APIs found in modern browsers, creating simple speech recognition and speech synthesis programs using JavaScript is actually pretty straightforward. In the following tutorial, I’ll show you how to use JavaScript to access your browser’s speechRecognition and speechSynthesis APIs so that you too can create programs you control with your voice; ones that not only can hear you, but ones that can speak to you as well. Come, let’s have a listen…

Explore JavaScript Courses

To start, it’s typically a good idea to explore which browsers best support the technologies we’re going to be working with. Here’s MDN’s spec sheet for the speechRecognition API: https://developer.mozilla.org/en-US/docs/Web/API/SpeechRecognition#Browser_compatibility. As you can see, it’s pretty much Chrome leading the way; however, Firefox has some capability as well. The same holds true for the speechSynthesis API: https://developer.mozilla.org/en-US/docs/Web/API/SpeechSynthesis#Browser_compatibility. Do note that Microsoft’s Edge browser enjoys some speech synthesis capabilities. David Walsh wrote a nice article on setting up the speechSynthesis API for cross-browser functionality; but, for simplicity’s sake and for the remainder of this tutorial, I’m going to assume the use of Chrome. 

So what does the code look like? A simple example of speech recognition code (written in JavaScript) looks like this (NOTE: You’ll probably have to open a new tab/window by clicking the “Edit in JSFiddle” link AND allowing your the browser access to your computer’s microphone (it should prompt you to do so).):

Try it out. Give the browser access to your computers mic and then try saying a few different words or phrases. If all goes according to plan, you should see what you say being written to the body of the html. If you’re having trouble getting it to work, try:

1) Making sure your computer has a mic and that your browser has access to it.

2) Making sure you have open only 1 application/tab/window that’s using the microphone.

3) Making sure to use Chrome as your browser and loading up the JSFiddle example in a new tab/window.

Okay, so the above example simply writes what the computer heard to the body of the html. That’s pretty interesting, but now let’s do something a bit more fancy; let’s tell the computer to do something for us! In the following example, trying opening up the Fiddle and telling the browser to change the background color of the HTML. The way I programmed it, you’ll have to say this exact phrase:

“Change background color to…” and then say any of the many colors recognized by CSS (e.g., “red,” “blue,” “green,” “yellow,”etc.).

Pretty cool, right? And really not all that difficult to pull off!

Now let’s look at giving the program a voice. I’m going to use Chrome’s default voice (yes, it sounds pretty robotic); but once you get the hang of it, feel free to read up on how to get and use different voices. Here we go; let’s see what it’s got to say:

Hear that? This time, the program audibly confirms that it’s changing the color of the background! Fantastic.

To recap all of this…

Speech Recognition

– The browser’s speechRecognition object has start and stop methods you can use to start and stop listening for audio input.

– The speechRecoginition object can react to for onend and onresult events.

– To get a string/text of what the computer heard, you can pass the onresult event to a function and then reference the event.results[0][0].transcript property.

Speech Synthesis

– The speechSynthesis object has a speak method that you can use to utter new SpeechSynthesisUtterances.

– You can pass a string (or number) value to the SpeechSynthesisUtterance constructor to create words or phrases.

    – pass that whole thing to the speak method and you’ve got a talking computer!

And there you have it. In this tutorial I’ve shown that it’s relatively simple to employ speech recognition and speech synthesis technology in your browser through the use of JavaScript. With this new tool set, my hope is that you’ll explore the wide array of possibilities that now exist. In theory, you can program your browser to execute most if not all of its functions at the sound of your voice. And you can make the browser say pretty much anything you want it to say. As usual, the limit is your imagination; so get out there and say something interesting! Better yet, have your browser say it for you. ;)

Explore JavaScript Courses

About the Author:

Accessibility 102: Beyond alt=””

September 27th, 2016

Communication is a fundamental social process, a basic human need and the foundation of all social organization. It is central to the Information Society. Everyone, everywhere should have the opportunity to participate and no one should be excluded from the benefits the Information Society offers.
Geneva Declaration of Principles, United Nations World Summit on the Information Society

The power of the Web is in its universality. Access by everyone regardless of disability is an essential aspect.
— Tim Berners-Lee, Inventor of the World Wide Web

What is web accessibility?

Web accessibility is the practice of making web content accessible and usable for people with disabilities.

Who needs accessibility?

Another way to put this question is: Who is disabled?

Since the web is primarily a visual medium, many people only think of blind users. However, a number of physical and cognitive impairments can create barriers to access.

  • Low-vision users may not be able to read text that is too small, or which has a low contrast ratio with its background.
  • Dyslexic users may have trouble with text that is too small or poorly typeset.
  • Color blind users may not be able to distinguish hyperlinks from surrounding text based on color alone, or interact with color-coded interfaces.
  • Deaf and hard-of-hearing users may not be able to hear or understand audio content, including speech (video, podcasts) or audio cues (alarms, bells).
  • Users with mobility or motor issues may not use a mouse to navigate onscreen content — they might use a keyboard, a single button, or an eye-tracking device.

In addition to users with long-term or permanent disabilities, many people experience periods of reduced ability. For example, someone with a broken arm may not be able to use a mouse.

Temporarily disabled users present a special hurdle. People with lifelong disabilities have often learned to use assistive technologies, developing strategies for handling online tasks. Users with new or temporary disabilities may not have the skills needed to compensate.

Elderly users also frequently experience difficulties with vision, hearing, and dexterity. Text size and color contrast are especially important issues for the aging. Older users also frequently do not have the tools or skills to compensate for their impairments.

It is difficult to say with certainty how many people have disabilities which hinder typical access to web content. The most frequently cited estimate is 20% (one in five).

Understanding Web Accessibility Needs

The foundation of effective accessibility practices is empathy. To design an accessible experience, you need to understand how users with disabilities are going to actually interact with your content.

Try It Out

One of the most profound things that you can do to understand the needs of disabled users is to actually try to use the web the way they do.

None of these practices will make you fully aware of accessibility issues, but they will make many of the most common problems immediately obvious.

Talk to People with Disabilities

There is no substitute for including a variety of people with a variety of disabilities into your design and review process. This isn’t feasible for every blogger and independent publisher, of course. But, if you are doing any sort of user testing at all, your user testing should include disabled people using web assistive technologies.

Basic Best Practices for Web Accessibility

There are a number of basic design decisions that can be made which will eliminate or greatly reduce the most common barriers to usability. More can always be done, but these will make a big difference.

Good alt Descriptions

You already know that you should add alt descriptions to your images. But are you writing good, helpfulalt descriptions?

  • Describe the image, without reference to the image.
    • Bad: A picture of George Washington.
    • Better: George Washington
  • Provide a description of the content, not just a title.
    • OK: George Washington
    • Better: George Washington, in his army uniform, standing in the snow at Valley Forge, surrounded by soldiers.
  • Mention aspects of the image which are meaningful to the surrounding content.
    • In an article about military costume: George Washington at Valley Forge, in his dark blue tricorn hat and lighter blue wool cloak with red lining.
    • In an article about the psychology of war: George Washington at Valley Forge, looking downward, while his starving soldiers sit on the ground in the background.

In most cases, the alt attribute is required for valid HTML5, so make it good.

Make infographics accessible with longdesc

If you have an image that contains a lot of information — such as a chart, infographic, or document photo — you can make the content of the image available using the longdesc attribute.

In HTML5, longdesc is used to specify a hyperlink to the text description of the image. This could be a link to separate document, but it is better (for SEO and usability) to link to a section of the current page.

<img src="complicated-infograph.jpg" alt="Short, but relevant, description of the image." longdesc="#infograph-desc">
.
.
.
<article id="#infograph-desc">
<h2>Title of Infograph</h2>
<p>....</p>
.
.
.
</article>

Sensible Document Structure with Semantic Markup

HTML5 added several sectional elements for structuring pages appropriately.

<body>
<header>
<!-- logo / site title here -->
<nav>
<!-- navigation menu -->
</nav>
</header>
<main>
<article>
<h1>Title</h1>
.
.
.
</article>
</main>
<aside>
<!-- Sidebar stuff -->
</aside>
<footer>
<!-- copyright info, contact info -->
</footer>
</body>

Some version of this basic outline works for all content sites, with minor adaptations. For example, a blog index page might have multiple <article> elements inside of <main>, each with an <h2> header. A page with comments might place them inside of individual <article> elements, inside an <aside>element, inside <main>.

Web apps require more variety, but many of the same principles apply:

  • exactly <h1> and one <main> on page;
  • <header>, <footer>, and <nav> used to identify site content that isn’t part of this specific document;
  • <article> defines a single piece of self-contained content;
  • <aside> defines secondary content related, but not integral to, its sibling.

Pages with clear structure and appropriate markup are easier for someone using a keyboard to navigate around the page. People using a screen reader can quickly jump to the relevant section without having to listen as a voice synthesizer lists all the navigation links in your menu. (Adding a skip to main content linkhelps with this as well.)

Within your articles or form, you can make your content more accessible by also making it more skimmable — small sections, meaningful headlines and sub-headlines, and well-organized lists contribute to easier keyboard navigation. Generous use of id tags (at least on all <h*> headlines) creates a linkable document outline that improves usability of everyone.

Make Your Structure Even More Accessible with ARIA Landmarks

ARIA landmarks are a set of attributes which assistive technologies use to identify the purpose of various document sections. There is overlap between ARIA landmarks and the new HTML5 sectioning element, but not a perfect overlap. It is best to use both.

<body>
<header>
<div role="banner"><!-- logo / site title here --></div>
<nav role="navigation">
<!-- navigation menu -->
</nav>
</header>
<main role="main">
<article>
<h1>Title</h1>
.
.
.
</article>
</main>
<aside role="complementary">
<!-- Sidebar stuff -->
</aside>
<footer role="content-info">
<!-- copyright info, contact info -->
</footer>
</body>

 

Relevant Anchor Text for Links (no “Click Here”)

It’s really easy to make a link and tell people to click here. Unfortunately, this is not accessible.

  • “Click here” is device dependent; not everyone clicks. Some people will tap, others will press enter, and still others will focus their eyes.
  • “Click here” provides no information about the content of the linked page. This reduces usability in at least three ways:
    • The user has to understand the surrounding text in order to understand “click here.” This increases cognitive load (bad for users with cognitive or neurological disabilities), and is difficult for those using screen reader technology.
    • If the surrounding text isn’t clear enough, the user has to open the page to find out what is there. For someone using assistive technology, this is a non-trivial operation.
    • Blind and low-vision users with screen readers cannot scan a document quickly the way sighted users can. They often skim through a page by jumping to headings and links to discover the page structure. “Click here,” breaks this interaction pattern.

Don’t Rely on Color

Color blind users will have difficulty when information is communicated only with color.

  • color coded alerts and badges in web apps
  • form labels that use color alone to indicate required and optional fields
  • charts and data visualizations that use color to identify components
  • hyperlinks that are distinguished from the surrounding text using only color (that is, without the default underlining)

Whenever possible, make sure that color-coded information is provided another way.

Color Contrast

Your dark gray text on a light gray background might look sleek and modern, but it’s also really hard to read. Color blind, the elderly, and low vision users will all have difficulty if the color contrast between text and background is too low.

The readability of various color combinations might seem a bit subjective, but there are clear color contrast standards in place.

  • AA (Minimally accessible)
    • 4.5:1 for normal text
    • 3:1 for large text (14pt with bold, or 18pt normal weight)
  • AAA (Highly accessible)
    • 7:1 for normal text
    • 4.5:1 for large text

You can use an online color contrast checker to ensure you are conforming to the readability standard.

Headers on Tables

Row and column labels in tables should use the <th> element (table header), and not the <td> (table data) element. Additionally, table data cells should be explicitly associated with their headers. This makes it much easier for screen readers to properly interpret a table.

Make Your Forms Accessible

Form accessibility is a big topic. If you design and build form-heavy sites or form-based web applications, you need to become familiar with the WAI-ARIA recommendation and associated best practices.

However, you can fix the majority of form accessibility issues with a few simple practices.

  • Every form element should have a label. Do not rely on placeholder text instead of a label. Do not use <h*>, <strong> or anything else for labels — use the proper <label> element.
  • Use the for attribute to associate the label explicitly to the form control. This is clearer for screen readers, and easier to select for those using certain types of assistive devices.
  • Use standard HTML5 form controls. Do not “roll you own” form control designs with images and clever JavaScript. You can style your elements with CSS all you want, but the underlying markup should be straightforward.
  • Don’t use tabindex>0. It is tempting to use tabindex to set the order in which form elements are accessed via keyboard tabbing. However, this feature is fundamentally broken. Instead of usingtabindex to set the tab order of your elements, make sure that your elements appear in your markup in the proper order.

Make Everything Available in HTML

Flash animation can be made accessible, but it is much easier to simply use standards-compliant, modern HTML5 and let assistive devices do the work. Similarly, embedding PDFs, PowerPoint slides, or other non-HTML ways of presenting content create a barrier between disabled users and that content.

Whenever possible (and it almost always is), provide your content in HTML. If there is a compelling reason to offer PDFs or PPTs, make sure that the content is also available in HTML. (PDFs can also be made more accessible, but HTML is easier.)

Moving Forward with Web Accessibility

Implementing these basic practices will go a long way towards making your web content accessible to the users with disabilities. But you can go even further. Web accessibility is a complicated, and evolving topic that cannot be summed up in a handful of tips.

For more information on Web Accessibility: