Learn Flux, Jquery and Screen-reader

A large number of people are unable to use the web effectively due to an impairment or disability.

As developers there are several tools and techniques we can use to make our web applications accessible, ensuring a great user experience that includes everyone.

We all agree that Accessibility is important. However, it’s a broad landscape and can be overwhelming figuring out where to start!

Erin Doyle is an expert in creating accessible React applications and has developed a course that will give you a concrete process for testing, refactoring, and building your applications with accessibility in mind.

After this course, you'll have a jump start on auditing and fixing accessibility issues in your applications and gain a better understanding of your target users and how to approach your web app design from their perspectives.


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

Develop Accessible Web Apps with React

screen-reader

There are many techniques for hiding content in user interfaces, and not all are created equal! Learn how different hiding techniques in HTML, CSS and ARIA impact keyboard and screen reader users in addition to visual display. As a bonus, we'll also take a look using a screen reader on a mobile device.

How Visible vs. Hidden Elements Affect Keyboard/Screen Reader Users

Actions contain no functionality, but rather describe an event in our application.  In this lesson we will describe our Actions as they relate to our application.  These Actions will then be available for triggering in our Views and for execution in our Store.

React Flux: Actions

In Flux our Components are referred to as Views, but they are the same familiar Components associated with any React development.  In Flux, however, we have the benefit of the architecture to keep us from having to pass down through a long chain of children Components any functionality that may be embedded in our Stores.  In this Lesson we will wire up all of our Components in record time utilizing the architecture we've already established.

React Flux: Components/Views

Stores are where the real work in our application is done.  Dispatchers broadcast Actions to all Stores, and the Stores registered to listen for those Actions will perform any logic needed to update our Views.  In this lesson we will establish our first Store and register the Actions we wish to respond to.

React Flux: Stores

Our build process during this series will utilize both gulp and browserify.  In this lesson we will take a moment to setup our environment and all of the tooling required to begin developing our Flux Application.  We've kept the build process very simple so porting it to grunt should be a breeze, but this also serves as a simple primer for those who may not be familiar with gulp.

React Flux: Development Environment Setup

Organizing modules and components is a critical aspect of the development of any single-page web application (SPA). In this lesson we will look at refactoring the Flux React store into a more module structure.

React Flux: Project Organization

Flux has four major components: Stores, Dispatchers, Views, and Actions.  These components interact less like a typical MVC and more like an Event Bus.  In this lesson we will start by creating our Dispatcher which queues up our Actions as Promises and executes them as they are received.  We'll also create an AppDispatcher which, unlike the Dispatcher, is more specific to our application.

React Flux: Overview and Dispatchers

As your React Flux application grows, it is inevitable that you start to see functionality and code repeated. With React, you can easily keep things DRY by using mixins.

React Flux: Remove Duplicate Code with Mixins

With this lesson, we will bring it all together, using what we've learned in the series to fisnish out the React Flux architecture example.

The completed code for this series can be found [here on Github](https://github.com/eggheadio/egghead-react-flux-example).

React Flux: Wrapping Up

By default, React doesn't have built in routing. We will add routing to our application with the react-routing-component.

React Flux: Routing with react-router-component

AngularJS is an open-source JavaScript framework, maintained by Google, that assists with running single-page applications. Its goal is to augment web-based applications with model–view–controller (MVC) capability, in an effort to make both development and testing easier.

angularjs

You can build single page applications with JQuery and/or AngularJS. In this lesson, John will look at some of the fundamental differences between the two approaches.

Application Wiring: JQuery vs AngularJS

jQuery is a fast, small, and feature-rich JavaScript library. It makes things like HTML document traversal and manipulation, event handling, animation, and Ajax much simpler with an easy-to-use API that works across a multitude of browsers. With a combination of versatility and extensibility, jQuery has changed the way that millions of people write JavaScript.

jquery

There are many ways of animating stuff on the Web. For example we can use CSS animations, vanilla JavaScript or jQuery library.

In this lesson we are going to learn how to use jQuery `slideUp()`, `slideDown()` and `animate()` functions to animate elements on a webpage in an easy and efficient way.

Animate Elements on a Webpage with jQuery

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

chrome-devtools

What's in a name? In this lesson, I'll explain the concept of naming interactive elements for screen reader users, including forms, buttons, and links. You'll learn how to debug accessible names and descriptions using the Chrome Accessibility Developer Tools (previously a Canary experiment, now in Chrome), using multiple labeling techniques. We'll also listen to the effects of proper accessible names and descriptions in Voiceover and Safari.

For more information and the nitty-gritty browser implementation algorithm, refer to WAI-ARIA 1.1: 
- https://www.w3.org/TR/wai-aria-1.1/#namecalculation
- https://www.w3.org/TR/accname-1.1/

What is Accessible Name Calculation?

Learn how to access the VoiceOver training and utility preferences on MacOs and how to make customizations to the screen reader.

Access and Customize VoiceOver Settings on MacOS

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

Navigate a Webpage with VoiceOver in Safari

Landmark regions are used by screen readers to make it easier for users to navigate the content on the page by defining the structure of the page.  Tools like the Rotor in VoiceOver rely on landmark regions to provide users with the ability to skip directly to the desired section of the page.  We can do this either using HTML5 landmark elements or `<div>` elements with aria roles. In the past, the recommendation was to use both but now we should only use one or the other.

The following are ARIA roles for landmark regions:
* `banner`
* `complementary`
* `contentinfo`
* `form`
* `main`
* `navigation`
* `search`
* `application`

## References
* https://dequeuniversity.com/assets/html/jquery-summit/html5/slides/landmarks.html
* https://www.w3.org/WAI/GL/wiki/Using_ARIA_landmarks_to_identify_regions_of_a_page
* https://www.w3.org/TR/html-aria/#docconformance

Define Landmark Regions of a web page using ARIA roles

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

Landmark regions are used by screen readers to make it easier for users to navigate the content on the page by defining the structure of the page. Tools like the Rotor in VoiceOver rely on landmark regions to provide users with the ability to skip directly to the desired section of the page. We can do this either using HTML5 landmark elements or <div> elements with aria roles. In the past, the recommendation was to use both but now we should only use one or the other.  We should prefer HTML5 to ARIA roles when possible.

The following are HTML5 elements for landmark regions:
* article
* aside
* header
* footer
* main
* nav
* section

## References
* https://dequeuniversity.com/assets/html/jquery-summit/html5/slides/landmarks.html
* https://www.a11ymatters.com/article/intro-html5-sectioning-elements/
* https://www.w3.org/TR/html-aria/#docconformance

Define Landmark Regions of a web page using HTML5 sectioning elements

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

Similar to Landmark Regions, Heading Levels are used by web browsers, plug-ins, and assistive technologies to provide in-page navigation.

## Rules
* Each page should have at least one `<h1>`
* Pages should be structured in a hierarchical manner
    * `<h1>`: being the most important (usually page titles or main content heading)
    * `<h2>`: usually major section headings
    * `<h3>`: sub-sections of the `<h2>`
    * and so on
* Do not skip heading levels - always follow consecutive order
* Do not use text formatting, such as font size or bold to give the visual appearance of headings.  
    * Use actual heading (`<h1>` - `<h6>`) for all content headings
* Do not use heading levels to achieve visual results only

## References
* https://webaim.org/techniques/semanticstructure/
* https://www.w3.org/WAI/tutorials/page-structure/headings/