Learn Hapi, Protractor 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

hapi is a battle-tested, full-featured, framework for building web applications and services with Node.js. With integrated support for essentials like authentication, caching and validation, and a powerful plugin system, hapi is ideal for projects and teams of any size.

This course will introduce hapi, some of it’s plugins, and guide you through many of hapi’s core features.

A rich framework for building applications and services hapi enables developers to focus on writing reusable application logic instead of spending time building infrastructure.

hapi

Introduction to Node Servers with Hapi.js

View engines, or template engines, allow you to maintain a clean separation between your presentation layer and the rest of your application. This video will demonstrate how to use the vision plugin with hapi to enable template support.

hapi.js - View engines 

hapi does not support serving static files out of the box. Instead it relies on a module called Inert. This lesson will cover serving static files using Inert's custom handlers.

hapi.js - Serving static files

Routing is a fundamental aspect of any framework. In this lesson, you'll learn how to use path parameters in hapi's router. We'll also touch on how the router uses specificity to order routes internally.

hapi.js - Route parameters

hapi doesn't ship with logging support baked in. Luckily, hapi's rich plugin ecosystem includes everything needed to configure logging for your application. This video will introduce good, a process monitor for hapi, and good-console, a reporter for good that outputs to standard out.

hapi.js - Logging with good and good-console

hapi makes handling POST and PUT payloads easy by buffering and parsing them automatically without requiring additional modules or middleware. This video will demonstrate how to handle JSON and form based request payloads via hapi's route configuration.

hapi.js - POST and PUT request payloads

hapi's reply interface is one of it's most powerful features. It's smart enough to detect and serialize objects, buffers, promises and even streams. This video will demonstrate first hand how to use the reply method to send your data to the client, no matter the format.

hapi.js - Replying to Requests

Think of hapi's `reply()` function as "what you want to say" and the `response` object as "how you want to say it". While `reply` controls the payload sent to the client, the `response` object will allow you to control how the client interprets the payload by manipulating status code, content type, state and more.

hapi.js - Using the response object

hapi automatically responds with JSON for any error passed to a route's `reply()` method. But what if your application needs errors rendered in HTML? This lesson shows how to implement friendly HTML error messages using hapi extension events.

hapi.js - Friendly error pages with extension events

hapi supports request validation out of the box using the joi module. Request path parameters, payloads, and querystring parameters can be validated with joi's simple, yet powerful, notation. This lesson covers the basics of validating requests using joi.

hapi.js - Request Validation with Joi

hapi has built-in support for parsing cookies from a request headers, and writing cookies to a response, making state management easy and straight-forward. It even has built in support for cookie encryption and auto detects when a cookie contains JSON, parsing or stringifying automatically.

hapi.js - Managing State with Cookies

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

hapi is a rock solid server framework for Node.js. Its focus on modularity and configuration-over-convention makes it the perfect match for any size development team. This video will introduce you to hapi by showing you the bare minimum needed to run a hapi server.

hapi.js - Up and running

Instead of using middlware, hapi provides a number of points during the lifecycle of a request that you can hook-in to provide additional functionality, called "extension events". This lesson will give you an introduction to using extension events, and show how they can be used to manipulate the request or response in-flight.

hapi.js - Extending the request with lifecycle events

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/

Search

Search Results