Learn Mocha, Safari and Xstream

screen-reader

Learn the basics of navigating through a web page using VoiceOver on MacOS in Safari.

Navigate a Webpage with VoiceOver in Safari

The Chrome Developer Tools (DevTools for short), are a set of web authoring and debugging tools built into Google Chrome.

chrome-devtools

Using our accessibility auditing toolkit we can find issues concerning landmark regions in our web application.  The react-axe library will report findings in the JavaScript console of the browser.  We could also run the axe browser extension to see the same results.  The tota11y browser extension will annotate any landmark regions on the page and therefore if none are annotated it may indicate that they aren't any (_NOTE: tota11y will only annotate landmark regions using aria roles and not those using HTML5 elements_).  Finally using the VoiceOver Rotor in Safari will show us whatever landmark regions have been defined in the Landmarks menu. 

Test for Landmark Region Accessibility Issues in React

We can find issues with heading levels by utilizing our accessibility auditing tools.  The library react-axe, as well as the browser extension axe, will report any findings concerning heading levels.  The browser extension tota11y will annotate all heading levels on a page and show any in red that have issues.  Finally, we can check the Rotor in VoiceOver in Safari.  The Rotor should have a Headings menu and will list in order all of them that are found on the page.  If headings are missing or inappropriate this will help us find them as well.

Test for Heading Level Accessibility Issues

React is one of the web’s most popular frameworks for building JavaScript applications. 

If you know what you’re doing, React can drastically simplify how you build, use, and maintain code.

Whether you’re a React newbie or you’re ready for advanced techniques, you can level-up with egghead. Explore our in-depth courses, lessons, and community resources to build more powerful applications and crack open your career.

react

Labeling inputs, elements, and widgets add context and clarity for assistive technology such as screen readers. Some elements do not already have some sort of labeling text being displayed visually, such as a `<button>` without descriptive text or an `<icon>` or part of a more complex widget.  Others may have some form of text label but it is not descriptive enough for those who cannot see it.  The addition of an `aria-label` attribute to the element will provide it with an accessible label so that when that element is focused by a screen reader, for instance, a label is read that better describes the element and what a user can expect from it.

Add Accessible Labels to Elements Whose Labels are Not Clear Enough

Labeling inputs, elements, and widgets add context and clarity for assistive technology such as screen readers. Some elements do not already have some sort of labeling text being displayed visually, such as a `<button>` without descriptive text or an `<icon>` or part of a more complex widget.  Others may have some form of text label but it does not provide enough context to be useful enough for those that cannot see it.  The addition of an `aria-label` attribute to the element will provide it with an accessible label so that when that element is focused by a screen reader, for instance, a label is read provides better context for the element and what a user can expect from it.

Add Accessible Labels to Provide Elements with More Context

Labeling inputs, elements, and widgets add context and clarity for assistive technology such as screen readers.  When there are already one or more other elements that themselves can be used to provide labeling text to another element an `aria-labelledby` attribute can be added to that element.  

Some examples of appropriate use cases for using an `aria-labelledby` are:
* Combine multiple labels together
* Associate headings with regions
* Label for a widget

Add an Accessible Label to an Element from the Text of Other Elements

Labeling inputs, elements, and widgets add context and clarity for assistive technology such as screen readers. Beyond adding accessible labels to elements and widgets we can also provide additional descriptions.  Similar to how an `aria-labelledby` attribute works, an `aria-describedby` attribute can link the text from another element or elements to be used as a description for the given element.  

Some example use cases for using an `aria-describedby` are:
* providing instructions
* providing important usage details

Add Accessible Descriptions to Elements

When dynamic changes occur to content on a page they are usually visually apparent to users who can see the page but may not be made apparent to users of assistive technologies. ARIA live regions provide a way to make those dynamic content changes able to be announced by assistive technologies.

## ARIA attributes
* `aria-live`: the priority with which updates are read
* `aria-atomic`: whether the screen reader should always present the live region as a whole, even if only part of the region changes
* `aria-relevant` - takes a list of what type of changes should be announced

## Resources
* https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/ARIA_Live_Regions
* https://www.w3.org/WAI/PF/aria-1.1/states_and_properties#aria-live
* https://www.w3.org/WAI/PF/aria-1.1/states_and_properties#aria-atomic
* https://www.w3.org/WAI/PF/aria-1.1/states_and_properties#aria-relevant
* http://html.cita.illinois.edu/nav/form/aria/index.php?example=3

Define a Live Region to Ensure Dynamic Changes are Announced by Assistive Technologies

Did you know every Mac comes with a fantastic screen reader built-in? Learn the basics for operating Voiceover with Safari, including common key commands, the web rotor, and the help menu. We'll also set up keyboard tabbing in Safari and OSX's System Preferences, two requirements for accessibility testing that occasionally trip up users. In a future lesson, we'll compare Voiceover to Windows screen readers, since they work quite differently.

#### Resources
- Apple Voiceover commands and gestures: https://www.apple.com/voiceover/info/guide/_1131.html
- WebAIM Voiceover Tutorial: http://webaim.org/articles/voiceover/

Using the Voiceover screen reader to test for accessibility

Cycle.js is a framework where your app is described as a simple function taking an event stream as input and outputting an event stream.

cycle

This lesson is the first in an introduction to Cycle.js. We will see how to build from scratch a toy version of Cycle.js. See how to use RxJS to create simple web apps, and how to separate logic from effects.

Separate Logic from Effects in Cycle.js

Mocha is a feature-rich JavaScript test framework running on Node.js and in the browser, making asynchronous testing simple and fun. Mocha tests run serially, allowing for flexible and accurate reporting, while mapping uncaught exceptions to the correct test cases.

mocha

Every dependable library needs to have tests to ensure that you don't push accidental bugs. In this lesson, see how you can set up mocha and chai to start testing your library.

Setting up Unit Testing with Mocha and Chai

Now that you've got everything set up with mocha and chai, it's time to actually write tests. In this lesson you'll learn how to use `describe` and `it` to outline your tests and make sure you don't break your library in the future.

Unit Testing with Mocha and Chai

Mocha is a testing framework that provides structure for unit tests. In this lesson, we will be setting up Mocha with npm and npm scripts, writing a "Hello World" unit test, then writing the code to make the test pass (as an example of Test Driven Development (TDD), with the "red-green-refactor" workflow).

JavaScript Testing Fundamentals: Hello world unit test with Mocha (in ES6)

In this lesson, we will use Chai's request method to test our Node application's API responses.
By the end of this lesson, you will know how to:
- install the prerequisites to use mocha and chai in your application
- test for HTTP status response codes
- test for a string of text on a page
- test for a json response and validate the properties of the object
- write tests that not only verify the response of your application, but the behavior as well


Test Node RESTful API with Mocha and Chai

Chai is a BDD / TDD assertion library for node and the browser that can be delightfully paired with any javascript testing framework.

chai

Writing great ES6 style Promises for Node.js is only half the battle. Your great modules must include tests as well to ensure future iterations don't break them. In this lesson, I show you a simple ES6 Promise in Node.js, then walk you through creating tests in Mocha using chai and chai-as-promised to test both resolve and reject methods.

Testing ES6 Promises in Node.js using Mocha and Chai

In this lesson, you will learn how to verify your API server is returning HTTP 400 responses when clients submit incorrect data. Returning HTTP 400 ensures that your clients are notified of the incorrect usage. Testing for them ensures your API returns errors instead of incorrect responses when supplied with incorrect data.

Test for HTTP 400 responses with Mocha and Chai

WAI-ARIA, the Accessible Rich Internet Applications Suite, defines a way to make Web content and Web applications more accessible to people with disabilities. It especially helps with dynamic content and advanced user interface controls developed with Ajax, HTML, JavaScript, and related technologies. 

aria

Animations can make people sick, or worse! By adding animation toggles and listening in to the user's system preference for reducing motion on OSX and iOS, we can give them more control over our interfaces. Animation can be a safety issue; let's do something about it!

Warning: there is a flashing animation in the video.

In this lesson:
- [prefers-reduced-motion](https://webkit.org/blog/7551/responsive-design-for-motion/)

WCAG 2.1, Guideline 2.3: Seizure risks
- https://www.w3.org/WAI/WCAG21/quickref/?versions=2.0#qr-seizure-does-not-violate

Your Interactive Makes Me Sick
- https://source.opennews.org/articles/motion-sick/

Accessible animations with reduced motion

Unit testing functions that invoke callbacks can require a lot of setup code. Using `sinon.spy` to create a fake callback function can simplify your unit tests while still allowing you to observe the output of the function you're testing.

Unit Test a Function that Invokes a Callback with a Sinon Spy

When testing functions that make HTTP requests, it's not preferable for those requests to actually run. Using the `nock` JavaScript library, we can mock out HTTP requests so that they don't actually happen, control the responses from those requests, and assert when requests are made.

Mock an HTTP request using Nock while unit testing

When mocking a JavaScript function during a unit test, it can be helpful to force a mock function to return a value of your choosing. This allows you to verify that functions you're testing will behave correctly for every possible use case.

Much like [`sinon.spy()`](https://sinonjs.org/releases/v7.0.0/spies/), [`sinon.stub()`](https://sinonjs.org/releases/v7.0.0/stubs/) creates a mock function that prevents a real function from running. But, unlike `spy`, it also allows you to declare what value you'd like the mock function to return.

Mock a function's return value using a Sinon stub

Node.js is a platform built on Chrome's JavaScript runtime for easily building fast, scalable network applications. Node.js uses an event-driven, non-blocking I/O model that makes it lightweight and efficient, perfect for data-intensive real-time applications that run across distributed devices.

node

Sometimes when writing a unit test, you know that the module you're testing imports a module that you would like to observe, or at the very least mock to prevent side effects like network activity or file system operations.

For JavaScript unit tests that run in Node, we can hijack the built-in `require` function by using the [`proxyquire`](https://www.npmjs.com/package/proxyquire) module, which allows us to mock one or more modules that are second-class dependencies in our unit test, replacing them with whatever we want.

This means we could replace functions with [no-ops](https://en.wikipedia.org/wiki/NOP_%28code%29) to prevent side effects, or replace them with [Sinon spies](https://egghead.io/lessons/mocha-unit-test-a-function-that-invokes-a-callback-with-a-sinon-spy) to observe the inner workings of the module you're testing.

In this video, we'll demonstrate the basics of using Proxyquire to prevent and observe a file system operation.

Topics

Instructors

Content Type