Learn Elixir, Jspm and Screen-reader

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

Learn to test for accessibility using Google's Lighthouse tool -- an open-source, automated tool for auditing web pages.
Lighthouse can audit with quite a few different tests (SEO, performance, PWA, etc.). We will only be looking at the Accessibility portion. The audit will show any issues that the site has with links to learn more as well as which elements specifically failed the tests.  


Test Web Accessibility using Lighthouse

Elixir is a dynamic, functional language designed for building scalable and maintainable applications.

Elixir leverages the Erlang VM, known for running low-latency, distributed and fault-tolerant systems, while also being successfully used in web development and the embedded software domain.

elixir

Some common uses for pattern matching in Elixir include checking conditions and passing parameters into functions. It's useful for pulling out only specific variables from collections of data.

Additional resources:
- [Elixir docs on pattern matching](https://elixir-lang.org/getting-started/pattern-matching.html)

Pattern match in conditions and function parameters in Elixir

Elixir uses `=` as an operator, but rather than assigning values to variables with it, it *matches* values on the right hand side of the `=` with the left side. This can be used in simple values, more complex data structures, and powerful condition checking.

Put into simpler terms, pattern matching is Elixir's way of assigning variables.

Additional resources:
- [Elixir docs on pattern matching](https://elixir-lang.org/getting-started/pattern-matching.html)

Pattern match values in Elixir

These videos include the introductory steps to writing your first Elixir function and beginning to understand some key concepts in Elixir that make it unique. 

Some of those concepts include:
- the Mix build tool
- project structure
- collections of functions written in modules
- function *arity*
- pattern matching and common uses for it
- the pipe operator

Getting Started with Elixir

The syntax to pass arguments into functions is akin to many other languages. Elixir functions are uniquely recognized when running based off of the number of arguments passed in (a term called *arity*). This means you can define functions with the same name, so long as a different number of arguments is passed in.

Arity is a key concept to be aware of when reading documentation and writing your own code.

Additional resources:
- [Information about arity](https://elixir-lang.org/getting-started/modules-and-functions.html#function-capturing)
- [Default arguments in functions](https://elixir-lang.org/getting-started/modules-and-functions.html#default-arguments)

Pass arguments into Elixir functions and understand arity

Elixir code is organized into groups of functions called modules. You can create your own modules and built on top of predefined modules that are a part of Elixir by default.

Additional resources: 
- [Getting started with Modules and function from Elixir docs](https://elixir-lang.org/getting-started/modules-and-functions.html)

Write a New Function Inside of an Elixir Module

Bootstrap a new Elixir project using Mix (a build tool included when you install Elixir), with its built in project generation.

Additional resources:
- [Official introduction to Mix](https://elixir-lang.org/getting-started/mix-otp/introduction-to-mix.html#our-first-project)

Generate a new Elixir project using Mix

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

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 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

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

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

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

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

screen-reader

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

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. 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

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.


Develop Accessible Web Apps with React

AI is amazing for generating code, but often leaves us staring at functions and libraries we've never seen before. This creates a huge problem: When things break (and they will break), we're lost. We don't understand the individual pieces, let alone how they interact. Knowing one part isn't enough; we need to see how unfamiliar components work together.

The solution? Real-world examples.

This lesson introduces ghx, a tool I built to do exactly that. ghx searches GitHub, finding actual code examples that use the specific combinations of functions and libraries that are tripping you up. Instead of generic documentation, you get concrete implementations. You can find the ghx repository at https://github.com/johnlindquist/ghx.

Here's the workflow we cover:

Identify the Unknown: Pinpoint the AI-generated code you don't understand – specific functions, libraries, or their interactions.

Search with ghx: Use ghx to search GitHub for examples using those terms together. ghx finds repos where those elements co-exist.

Consolidate Examples: ghx combines the relevant code snippets from those examples into a single, digestible file.

Ask the AI (Again, but Better!): Feed this consolidated code to an AI (like a coding-focused model in an AI studio). Now, instead of asking general questions, you can ask targeted questions based on real-world usage:

"Explain how these functions are used together in these examples."

"What are some common use cases for this combination of libraries?"

"Show me alternative code snippets that achieve the same result."

"Can you identify potential problems or areas for improvement, based on these examples?"

Iterate. Use your improved understanding to make changes, and then repeat the process to debug.

By leveraging ghx and targeted AI prompting, we transform from being lost in a sea of unfamiliar code to actively learning from how others have solved similar problems. We gain a deeper understanding of our AI-generated codebase, making debugging, modification, and future development far more manageable. This gives you the tools to understand, debug and improve your own code.

John Lindquist

How to Work with AI-Generated Code You Don't Understand

In this less we create a custom Zod schema using `z.custom`.

The example case covers room numbers validation: it must start with an uppercase letter followed by three digits. `z.custom` allows the creation of a brand new custom schema with a callback function that returns a boolean indicating validity.

We highlight a challenge with type inference in Zod's custom schemas: callback parameter types don't get aligned automatically - type-safety must be explicitly defined using type parameters.

We run tests against various room numbers and demonstrate how to effectively validate inputs and manage error messages.


Tomasz Ducin

Create Custom Zod Schemas and Validate project-specific data

Create custom validation logic in Zod using z.custom, for primitive values, ensuring type safety and proper error messages for room numbers.


Excessive properties refer to any additional attributes that are not explicitly listed in an object schema. When creating an object based on a schema, it is important to ensure that only the defined properties are included.

In TypeScript, if an object is created with an extra property that isn't defined in the schema, TypeScript will not raise an error unless the type is explicitly annotated. When the type is annotated, TypeScript will issue an error indicating that the extra property is not allowed.

Zod provides a strict utility to enforce similar checks. This feature ensures that only specified properties are allowed in an object schema. When unnecessary properties are added at both the top level and within nested schemas, Zod will throw errors indicating unrecognized keys.

Adding an unrecognized property to a Zod schema results in an error message that specifies which keys are not recognized. Applying strict checks on nested schemas ensures that all levels of the data structure are validated correctly.


Make Excessive Object Properties Fail on Zod Validation

Prevent excessive properties in TypeScript and Zod schemas using strict checks for better data validation

In this lesson we discuss how Zod works with TypeScript to handle special types like `undefined`, `null`, `any`, `unknown`, `never` and `void`.

We modify our room booking schema to demonstrate the use of `optional` and `nullable` Zod utilities.

By using `.optional`, we allow a property to be either its _original type_ or `undefined`. With `.nullable`, we allow it to be either its _original type_ or `null`. Finally, `.nullish` allows a value to be either its _original type_, `null`, or `undefined`.

For all cases, we run tests to show how these schemas work in practice, as well as how TypeScript infers types.


Declare Lack of Value in zod (optional, nullable and nullish)

use Zod for TypeScript schemas, including handling undefined, null, and special types like optional and nullable values, as well as any, unknown never and void

In this lesson we make use of partial validation of large and nested schemas in Zod.

Instead of creating many small schemas, which can complicate maintenance, Zod allows for the extraction of specific parts of a schema using the concept of ".shape". It "unwraps" the object schema, enabling access to sub-schemas within specific properties.

Additionally, we can use the `.unwrap` to get into element schemas of altered schemas such as `.optional` or `.array`.

Simplify working with complex schemas without the need to break them into hundreds of small schemas.

Use Zod Schemas partially using shape and unwrap

Manage large and nested Zod Schemas by extracting partial validations using shape and unwrap utilities

In this lesson we cover implementing sets and maps in Zod.

Using `z.set`, a schema for string-based amenities is created. We demonstrate how validation works by intentionally introducing errors and customizing error messages for better clarity.

Next, a map is created for existing guestDetails schema using `z.map`, with string keys and an existing `z.object`-based schema. The validation process is shown again by deliberately breaking the schema, such as omitting the age property, which triggers appropriate error messages.


Validate maps and sets using Zod schemas

Use sets and maps in Zod for schema validation, ensuring type safety for both keys and values.

In this lesson we'll use a few predefined schemas which will serve as constituents to create union and intersection schemas.

Three room booking schemas are defined: _single_, _double_, and _suite_. Each schema has slight differences in the structure.

The `z.union` utility is used to create a union of these schemas, allowing for validation against any of them. Type inference (using `z.infer`) for the room booking schema produces a union of object literals, exactly like in TypeScript.

We also create an intersection using `z.intersection`, combining room booking details with discount information.

These techniques enhance data validation and allow to make `zod` aligned even more with `TypeScript`.


Define Unions and Intersections with Zod

implement unions and intersections in Zod schemas for example domain related objects, enhancing TypeScript validation with clear examples

This lesson demonstrates how to provide runtime type-safety for arrays in TypeScript applications.

First we need to understand the challenges behind ensuring array type-safety in TypeScript. We explain how TypeScript infers arrays with an undefined length, making it difficult to guarantee that array accesses are safe.

Zod schemas provide the `z.array` to define arrays of various element types. 

We compare how utilities such as `.min`, `.max` and `.nonempty` get reflected in inferred TypeScript types, and how zod processes the validation.


Declare Precise Array Types within Zod Schemas

Provide array type safety in TypeScript using Zod schemas, including handling non-empty arrays for better validation

In this lesson we make string-based schemas more specific using Zod in TypeScript. We focus on defining allowed values for a room type, showing how to use literals and enums effectively.

Zod's `z.literal` method allows us to specify a single allowed value for a string schema. For example, if we want to define a room type as `"premium"` and make it backward-type-safe in TypeScript, we can use `z.literal("premium")` to ensure that only this value is valid.

`z.enum` lets us define a set of allowed string values. This is useful when we have multiple options for room types, like `"standard",` `"premium"` or `"childrenFriendly"`. 

`z.enum` creates a union of TypeScript-compatible string literals, making it easy to validate against multiple values. Zod enums can be used to extract or exclude specific values from the enum.

Finally, zod's `z.nativeEnum` a native enum creates an equivalent of TypeScript's native `enum` ("real enums", we could say).

We can validate against all these values just like we do with literals and enums.


Work with Zod Literals and Enums Effectively

Use Zod for string schemas in TypeScript, including literals, enums, and native enums for room type validation

In this lesson, we dive into the Zod's `refine` utility, allowing defining more complex schema validation **on top of existing schemas and utilities**.

Sometimes, we need special validation rules for our applications to work correctly. The `refine` utility lets developers create their own validation rules. This method's uses a callback to check if the input is valid. We also create meaningful messages when something doesn’t meet the validation rules.

We use a practical example involving a room booking schemawith `dueDate` and `price` property refinement.


Apply Schema Custom Refinement with Zod

Enhance your TypeScript validation skills with Zod's refine utility for custom room booking schemas, focusing on date and price validation.


Search

Search Results