Learn Docker, Screen-reader and Xstream

While "It works on my computer" might give you an excuse to close a bug ticket in the backlog, it doesn't really work when you're working on a team.

You need to ensure that your application can run regardless of what hardware your teammates are running or libraries they have installed.

Docker solves this problem by collecting everything your application needs to run into a container.

Containers aren't just for source code. They can hold configuration, scripts, and even their own filesystem. It's similar to a Virtual Machine, without having to bring a full operating system along for the ride.

Because containers run in isolation, there is some configuration involved to allow for files to be saved and containers to communicate with one another.

One of the most useful ways to get your head around Docker is to see it in action.

Follow along with Joel Lord as he works through the process of preparing an application to run in separate containers for the frontend and backend of an application that searches for gifs and re-encodes them with a caption supplied by the user.

You'll see how to configure the separate containers to communicate with one another, work with environment variables, and persist data to your local machine. Along the way, you'll pick up some tips on useful commands and bash scripting. Finally, you'll learn how to use Docker Compose to make it easy to run multiple containers simultaneously.


Docker containers wrap a piece of software in a complete filesystem that contains everything needed to run: code, runtime, system tools, system libraries – anything that can be installed on a server. This guarantees that the software will always run the same, regardless of its environment.

docker

Containerize Full-Stack JavaScript Applications with Docker

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

In this course we will take a simple Node.js app that connects to a MongoDB database and uses an Express web server, and learn how to setup a full software development deployment process as well as how to properly “Dockerize” the app. 

We’ll step through setting up proper version control techniques, managing configuring within the environment, setting up proper build/deploy/run processes, and all with abiding by Docker best practices. We’ll also make sure our deployment is setup for scale, and have consistent development practices in place for reliable app deployments.

Build a Twelve-Factor Node.js App with Docker

Zeit’s mission statement is to ‘Make Cloud computing as easy and accessible as Mobile computing.’ To that end, they’ve released some pretty amazing and powerful tools. In this course we’re going to take a look at `now`, their deployment tool, to see why it’s hands-down the simplest way to launch node applications, docker containers and even static files to the cloud.


We’ll also dig into some of now’s more advanced capabilities, including host aliasing, environment variables and integration with hosted databases.

Deploy Web Apps with Zeit Now

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?

screen-reader

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/

Correctly Define Heading Levels of a Web Page

The pluggable linting utility for JavaScript and JSX.

eslint

We have a number of options to use when testing for accessibility issues concerning alternative text for images.  The react-axe library and axe browser extension will both report when an image is missing alternative text.  The tota11y browser extension will annotate any images that are missing alternative text.  Running eslint with the eslint-plugin-jsx-a11y plugin installed will report on any `<img>` elements missing an `alt` attribute.  Finally, we can use a screen reader to actually hear what is read when an image has focus.

Test for Image Alternative Text Accessibility Issues

Images must have text alternatives that describe the information or function 
represented by them so they can be read and understood by those using screen readers.

## Alternative text for images
* All `<img>` elements should have an `alt` attribute provided
    * When not provided many screen readers will fallback to reading the file name instead
* The `alt` value should not include words like _“image”_, _“picture”_ or _“icon”_
    * Screen readers are already announcing that the element is an image
* Images that are decorative only and provide no information or function to the page should be hidden from Assistive Technologies by providing an empty `alt` attribute (`alt=””`)

## References
* https://www.w3.org/WAI/tutorials/images/
* https://www.w3.org/WAI/tutorials/images/decision-tree/
* https://www.w3.org/WAI/tutorials/images/tips/
* https://www.w3.org/WAI/tutorials/images/informative/
* https://www.w3.org/WAI/tutorials/images/functional/
* https://www.w3.org/WAI/tutorials/images/textual/

Define Images with Appropriate Text Alternatives

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

Keyboard/screen reader navigation relies on focus proceeding in a logical and linear 
order and not getting lost such that the user does not know where they are 
or how to get back to the desired point in a web page.

## References
* https://www.w3.org/TR/wai-aria-1.1/#managingfocus
* https://developers.google.com/web/fundamentals/accessibility/focus/
* https://reactjs.org/docs/accessibility.html#programmatically-managing-focus 
* https://reactjs.org/docs/accessibility.html#programmatically-managing-focus
* https://reactjs.org/docs/refs-and-the-dom.html
* https://reactjs.org/docs/hooks-reference.html#useref
    * https://medium.com/@teh_builder/ref-objects-inside-useeffect-hooks-eb7c15198780
* https://www.gatsbyjs.org/blog/2019-07-11-user-testing-accessible-client-routing/

Appropriately Set the Focus on Each Page Load of a Web Application

Kubernetes is an API to a computer. Multiple computers actually. Here we'll talk about what K8s is, how you can choose between the plethora of K8s related hosting options, and what the process looks like for getting some containers running.

Topics

Instructors

Content Type