Learn Ember, Leaflet and Screen-reader

In this course, Colby is going to do a deep dive into creating a full store for your products. You'll learn how to set up and use GraphCMS as your content management system. You'll learn about the Cloudinary UI extension and how to use it to host your images. You'll learn about Snipcart and using the useSnipcart hook to handle the cart state and the checkout. You'll learn how to implement Stripe as your payment gateway. And lastly, you'll learn how to deploy a Next js app to vercel from github with environment variables.

snipcart

Ecommerce Product Management & Storefront with GraphCMS, Snipcart, & Next.js

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

If you've ever worked on a website for a business, there's a good chance you've included a map.

A Google Map embed is sufficient for showing a location, but doesn't leave you many customization options.

React Leaflet to the rescue!

In this course, Colby Fayock will guide you through a series of lessons and challenges that will build your map making skills as you build out a web app for a fictional restaurant.

You'll get practice with handling API keys and using React Hooks to implement a custom interactive map complete with metadata and additional overlays.

This course has built-in challenges that you are encouraged to pause and work through, but feel free to just watch.

Build Maps with React Leaflet

In this collection, you'll learn the basics of creating a new map in your React application with React Leaflet. We'll walk through adding the map itself as well as adding markers with popups, different shapes, and increasingly complex features to your map!

Mapping with React Leaflet

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

A JavaScript framework for creating ambitious web applications.

ember

In this lesson we will create an `updateContent` method that sets the value of our `content` property to the current epoch timestamp. We need to call `toString()` on the `Date.now()` method in order to make TypeScript happy.

```
updateContent() {
  this.content = Date.now().toString()
}
```

We create a constructor that takes the options parameter, call `super(options)` and call into our `this.updateContent()` method.

```
constructor(options) {
  super(options)
  this.updateContent()
}
```

When we refresh our page we can see that the value of `content` is set to the epoch timestamp. 

To make the content really dynamic we use `setInterval()` to call into `updateContent` each second: `setInterval(() => this.updateContent(), 1000)`.

When we save our file we see that our content does not get updated anymore and when we check the console we see that we get an error telling us that: The 'content' property on the my-component component was changed after it had been rendered. The error also informs us that we should Use the @tracked decorator to mark this as a tracked property.

We add the @tracked decorator to our property, we import tracked from @glimmer/component and we refresh the page. We verify that `content` gets updated each second.

We change our `updateContent` to add our the timestamp to the array. When we use `this.items.push(this.content)` to achieve this we see that the list does not get updated. This is because the `@tracked` decorator only tracks the re-assignment of properties.

The way to get this working is by re-assigning our `items` array inside `updateContent`. We assign a new array, de-structure the current items array and add the new content.

```
this.items = [...this.items, this.content]
```



Use dynamic data in a GlimmerJS component

In this lesson we will use the ember cli to generate a new component. Running `ember g glimmer-component my-component` generates the template and component class. We change the content of our component and add it to the main template in order to show it on the page.

Create a new GlimmerJS component

In this lesson we will add a variable called `content` to our component class, initialize it as a string and display the variable in our class using the double curly braces syntax, which is the handlebars expression for expressions, `{ {content }}`. 

After this we create a new class variable called `items`, initialize it as an array with strings. To display this list in our template we add a `<ul></ul>` and inside this unordered list we use the handlebars `each` helper to display the list items.

And inside our each statement we will print a `<li>` tag and render `{{ item}}` inside it.

```
<ul>
  {{#each items key="@index" as |item| }}
    <li>{{item}}</li> 
  {{/each}}
</ul>
```



Use template variables in a GlimmerJS component

Leaflet is the leading open-source JavaScript library for mobile-friendly interactive maps. Weighing just about 38 KB of JS, it has all the mapping features most developers ever need.

leaflet

Leaflet makes creating maps in the browser *dead simple*. With some HTML and 3 lines of JavaScript, we can quickly have a map displaying.

Get Started with LeafletJS Mapping

With a basic map in place we can add shapes, like US states. We will then see how to style the shapes to make a visually appealing map.

Adding Shapes to Maps with Leaflet and GeoJSON

Rendering GeoJSON data on a map and interacting via mouse over, mouse out, and click.

Interactive Leaflet Maps with GeoJSON data

[GlimmerJS](https://glimmerjs.com/) is a UI component library built by the Ember.js team. It is fast and lightweight and uses a combination of TypeScript and Handlebars to build the components.   

In this lesson we will use the Ember CLI to initialize a new GlimmerJS project.

We will start by installing Ember CLI globally by running `npm install -g ember-cli/ember-cli`.

Next we will use the `ember` command to create our new project by running `ember new egghead-glimmer -b @glimmer/blueprint` . 

When our project is created we `cd` into the project directory and start the development server. We will view the page in the browser and change the base template.

Initialize a project using Glimmer.js

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?

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.

Search

Search Results