Merge master into gjs branch

.gitignore

@@ -1,6 +1,7 @@
 # compiled output
 /dist/
 /declarations/
+/tmp/
 
 # dependencies
 /node_modules/

guides/release/tutorial/part-1/component-basics.md

@@ -1,4 +1,4 @@
 <!-- Heads up! This is a generated file, do not edit directly. You can find the source at https://github.com/ember-learn/super-rentals-tutorial/blob/master/src/markdown/tutorial/part-1/04-component-basics.md -->
 
 In this chapter, you will _[refactor](../../../components/introducing-components/#toc_breaking-it-into-pieces)_ your existing templates to use components. We will also be adding a site-wide navigation bar:
 
@@ -58,16 +58,15 @@
 
 Let's try it out by editing the index template:
 
-```handlebars { data-filename="app/templates/index.hbs" data-diff="-1,-2,+3,+7,-8" }
+```handlebars { data-filename="app/templates/index.hbs" data-diff="-1,-2,+3,-7,+8" }
 <div class="jumbo">
   <div class="right tomster"></div>
 <Jumbo>
   <h2>Welcome to Super Rentals!</h2>
   <p>We hope you find exactly what you're looking for in a place to stay.</p>
   <LinkTo @route="about" class="button">About Us</LinkTo>
-</Jumbo>
 </div>
-
+</Jumbo>
 ```
 
 ## Refactoring Existing Code
@@ -80,7 +79,7 @@
 
 Let's do the same for our other two pages as well.
 
-```handlebars { data-filename="app/templates/about.hbs" data-diff="-1,-2,+3,+11,-12" }
+```handlebars { data-filename="app/templates/about.hbs" data-diff="-1,-2,+3,-11,+12" }
 <div class="jumbo">
   <div class="right tomster"></div>
 <Jumbo>
@@ -91,11 +90,11 @@
     AND building Ember applications.
   </p>
   <LinkTo @route="contact" class="button">Contact Us</LinkTo>
-</Jumbo>
 </div>
+</Jumbo>
 ```
 
-```handlebars { data-filename="app/templates/contact.hbs" data-diff="-1,-2,+3,+19,-20" }
+```handlebars { data-filename="app/templates/contact.hbs" data-diff="-1,-2,+3,-19,+20" }
 <div class="jumbo">
   <div class="right tomster"></div>
 <Jumbo>
@@ -114,8 +113,8 @@
     <a href="mailto:[email protected]">[email protected]</a>
   </address>
   <LinkTo @route="about" class="button">About</LinkTo>
-</Jumbo>
 </div>
+</Jumbo>
 ```
 
 After saving, everything should look exactly the same as before, and all the tests should still pass. Very nice!

guides/release/tutorial/part-1/orientation.md

@@ -1,4 +1,4 @@
 <!-- Heads up! This is a generated file, do not edit directly. You can find the source at https://github.com/ember-learn/super-rentals-tutorial/blob/master/src/markdown/tutorial/part-1/01-orientation.md -->
 
 In this chapter, you will install _[Ember CLI](https://cli.emberjs.com/release/)_, use it to generate a new Ember project, and add some basic templates and styles to your new app. By the end of this chapter, you should have a landing page with Professor Tomster's cute little face featured on it:
 
@@ -24,7 +24,7 @@
 
 ```shell
 $ ember --version
-ember-cli: 6.4.0
+ember-cli: 6.7.0
 node: 18.20.8
 os: linux x64
 ```
@@ -37,8 +37,8 @@
 
 ```shell
 $ ember new super-rentals --lang en
-installing app
-Ember CLI v6.4.0
+installing classic-build-app-blueprint
+@ember-tooling/classic-build-app-blueprint v6.7.0
 
 Creating a new Ember app in /home/runner/work/super-rentals-tutorial/super-rentals-tutorial/dist/code/super-rentals:
   create .editorconfig
@@ -159,7 +159,7 @@
 ├── package-lock.json
 └── testem.js
 
-16 directories, 37 files
+17 directories, 37 files
 ```
 
 We'll learn about the purposes of these files and folders as we go. For now, just know that we'll spend most of our time working within the `app` folder.

guides/release/tutorial/part-1/working-with-data.md

@@ -1,4 +1,4 @@
 <!-- Heads up! This is a generated file, do not edit directly. You can find the source at https://github.com/ember-learn/super-rentals-tutorial/blob/master/src/markdown/tutorial/part-1/08-working-with-data.md -->
 
 In this chapter, we will remove the hard-coded data from our `<Rental>` component. By the end, your app would finally be displaying real data that came from the server:
 
@@ -243,7 +243,7 @@
 │       └── teaching-tomster.png
 └── robots.txt
 
-4 directories, 6 files
+5 directories, 6 files
 ```
 
 You can verify that everything is working correctly by navigating to `http://localhost:4200/api/rentals.json`.

guides/release/tutorial/part-2/ember-data.md

@@ -1,4 +1,4 @@
 <!-- Heads up! This is a generated file, do not edit directly. You can find the source at https://github.com/ember-learn/super-rentals-tutorial/blob/master/src/markdown/tutorial/part-2/11-ember-data.md -->
 
 In this chapter, we will work on removing some code duplication in our route handlers, by switching to using EmberData to manage our data. The end result looks exactly the same as before:
 
@@ -346,6 +346,19 @@
   namespace: 'api',
 });
 
+/* This is to account for a deprecation that shipped in ember-cli 6.4
+   with ember-data v5.6 which needs a blueprint update to avoid the
+   deprecation that is otherwise irrelevant for tutorial purposes.
+*/
+import { registerDeprecationHandler } from '@ember/debug';
+registerDeprecationHandler((message, options, next) => {
+  if (message.includes('Using WarpDrive with EmberJS requires')) {
+    return;
+  } else {
+    next(message, options);
+  }
+});
+
 if (macroCondition(isDevelopingApp())) {
   importSync('./deprecation-workflow');
 }

guides/v6.6.0/accessibility/application-considerations.md

@@ -0,0 +1,58 @@
+In this section, you will learn about the configurations and libraries that affect an entire application's accessibility.
+
+## Lang Attribute
+
+Declaring the language of the HTML document allows users to better understand your content.
+
+> Both assistive technologies and conventional user agents can render text more accurately when the language of the Web page is identified. Screen readers can load the correct pronunciation rules. Visual browsers can display characters and scripts correctly. Media players can show captions correctly. As a result, users with disabilities will be better able to understand the content.
+> [WCAG Success Criterion 3.1.1: Intent](https://www.w3.org/WAI/WCAG21/Understanding/language-of-page.html#intent)
+
+A primary language should be defined on the `<html>` element's `lang` attribute. For new apps, you can use the `--lang` option on the `ember new` command to set the language for a new application.
+
+```bash
+ember new mon-app --lang fr
+```
+
+This command will create your application with French defined as the primary language
+on the `<html>` element's `lang` attribute.
+
+For existing Ember apps, a developer may edit the `index.html` file or leverage [ember-intl](https://github.com/ember-intl/ember-intl).
+
+The `html` element may not have multiple `lang` _values_. If an element contains content in a language different from the primary, then you can provide the element its own `lang` attribute.
+
+![For example, the HTML tag may have a lang of "es" while a paragraph may have a lang of "en"](/images/accessibility/application-considerations/lang.png)
+
+<div class="cta">
+  <div class="cta-note">
+    <div class="cta-note-body">
+      <div class="cta-note-heading">Zoey says...</div>
+      <div class="cta-note-message">
+        <p>
+        To learn more about the lang attribute and how to use it: <a href="https://developer.mozilla.org/en-US/docs/Web/HTML/Global_attributes/lang">https://developer.mozilla.org/en-US/docs/Web/HTML/Global_attributes/lang</a>. Unsure which language subtag to use? Try <a href="https://r12a.github.io/app-subtags/">the Language Subtag Lookup tool</a>.
+        </p>
+      </div>
+    </div>
+    <img src="/images/mascots/zoey.png" role="presentation" alt="">
+  </div>
+</div>
+
+## Accessibility addons
+
+Any addon that will provide UI elements to the application should be evaluated for accessibility before use.
+
+There are some existing Ember addons that may help you make your app more accessible. Each addon should be evaluated for its own usefulness and merit- you may find in some instances, that it would be better to implement the ideas presented in the addon in your own application.
+
+Here are some examples of accessibility-focused addons created by many people throughout the Ember community:
+
+- [ember-a11y-landmarks](https://github.com/ember-a11y/ember-a11y-landmarks) - Ember addon to help with landmark roles for better accessibility
+- [ember-component-focus](https://github.com/ember-a11y/ember-component-focus) - A mixin for adding methods to your Ember components that help you manage the currently focused element.
+- [ember-steps](https://github.com/rwjblue/ember-steps) - Declarative create wizards, tabbed UIs, and more
+- [ember-page-title](https://github.com/tim-evans/ember-page-title) - Page title management for Ember.js Apps
+- [ember-self-focused](https://github.com/linkedin/self-focused/tree/master/packages/ember-self-focused) - Focus on route on transition
+- [ember-keyboard](https://github.com/patience-tema-baron/ember-keyboard) - An Ember.js addon for the painless support of keyboard events
+- [ember-a11y-testing](https://github.com/ember-a11y/ember-a11y-testing) - A suite of accessibility tests that can be run within the Ember testing framework
+- [a11y-announcer](https://github.com/ember-a11y/a11y-announcer) - An accessible ember route change announcer
+- [ember-template-lint](https://github.com/ember-template-lint/ember-template-lint) - linter for Ember templates
+  ![Template Linting Preview](/images/accessibility/application-considerations/template-lint.png)
+
+While there are quite a few moving parts, here's a cheat sheet to get you started: [Accessibility Cheat Sheet](https://moritzgiessmann.de/accessibility-cheatsheet/)

guides/v6.6.0/accessibility/components.md

@@ -0,0 +1,93 @@
+When crafting an accessible component, the first and most important thing is that the component should render valid HTML. 
+
+Both the HTML and ARIA specifications have been written in a way that make them work together. Semantic HTML provides the necessary _context_ to screen readers.
+
+Browsers have implemented the spec in a way that provides functionality for free. 
+For example, consider this code sample: 
+
+```html
+<button type="submit">Submit Form</button>
+```
+
+Here is what would be provided by the browser that the developer would otherwise need to provide: 
+
+- keyboard interactions on interactive elements (i.e., using the `ENTER` key to activate a `<button>` element)
+- a machine-readable name 
+- a place in the `TAB` order of the page
+- the intrinsic role of button 
+
+If the interactive element would be written another way, such as: 
+
+```html
+<div>Submit Form</div>
+```
+
+The developer would need to write the following additional code: 
+
+- add the role of button (`role="button"`)
+- add the button to the tab order (`tabindex="0"`)
+- add the keyboard functionality (a JavaScript function to activate the associated action when the `ENTER` key is pressed)
+
+This is just one example of how developers can use HTML's built in features to improve accessibility and reduce the need for custom code. Read more here: ["Just use a button"](https://developer.paciellogroup.com/blog/2011/04/html5-accessibility-chops-just-use-a-button/).
+
+## Focus management in components
+
+Focus is one of the main ways a component can communicate with screen readers.
+
+For example, when you hit tab on a page or click on a form field, a blue border usually appears around the element. This kind of behavior is part of focus.
+Developers can use JavaScript to control the focus in their apps, enabling keyboard navigation and usability by screen readers.
+For example, if there is a button that launches a modal with interactive elements in it, that button's click handler needs to contain code that brings focus to the new content.
+
+This article is a good launching point for learning more about focus: [Keyboard accessibility](https://webaim.org/techniques/keyboard/)
+
+Here are some other tips to get you started:
+
+- There is a difference between browse mode and focus mode in screen readers- see ["Focus Please"](https://codepen.io/melsumner/live/ZJeYoP).
+- Focus should return from whence it came- for example, if a `<button>` element opens a modal, the focus should then be returned to that same trigger button once the modal is closed. 
+- Note: `role="presentation"` or `aria-hidden="true"` should not be used on a focusable element.
+
+
+## Accessible name
+
+All interactive elements must have an accessible name. But what does that mean, exactly? 
+
+Because the code that is written must be readable by other machines (assistive tech like screen readers, for example), there is documentation about how this accessible name is determined: [Accessible Name and Description Computation](https://www.w3.org/TR/accname-1.1/). 
+
+However, the most common methods for providing accessible names can be reviewed here. 
+
+### Adding a label to an input element
+
+Every `<input>` element should have an associated `<label>` element. To do this, the `<input>` element's `id` attribute value should be the same as the `for` attribute value on the `<label>`. Ember has a built-in `unique-id` helper that can generate unique ids that you can use like this:
+
+![Separate input and label elements with a connection established by matching for and id attributes](/images/accessibility/component-considerations/input-for-id.png)
+
+```html
+{{#let (unique-id) as |id|}}
+  <label for={{id}}>Name:</label>
+  <input id={{id}} name="name" value="" type="text" />
+{{/let}}
+```
+
+It is also valid to wrap the `<label>` element around the `<input />` element: 
+
+![A child input element nested within a parent label element without any for and id attributes](/images/accessibility/component-considerations/input-nested.png)
+
+```html
+<label>Name:
+  <input name="name" value="" type="text" />
+</label>
+```
+
+However, this option can be a little harder to apply styles to, so both should be tested before determining which approach to use.
+
+<div class="cta">
+  <div class="cta-note">
+    <div class="cta-note-body">
+      <div class="cta-note-heading">Zoey says...</div>
+      <div class="cta-note-message">
+To dig deeper into accessible input patterns in Ember check out the <a href="https://emberjs-1.gitbook.io/ember-component-patterns/form-components/input">ember-component-patterns article on Input Fields</a>.
+      </div>
+    </div>
+    <img src="/images/mascots/zoey.png" role="presentation" alt="">
+  </div>
+</div>

guides/v6.6.0/accessibility/index.md

@@ -0,0 +1,16 @@
+Ember provides a few ways to help developers more easily produce accessible applications, and this section of the guides will more explicitly assist with that. 
+
+![Ember Loves Accessibility](/images/accessibility/index/a11y-mascots.png)
+
+Accessibility should be considered at the start of a project, whether that project has named accessibility an explicit goal or not. Since no one can predict anyone else's future (including whether or not they will need assistive technology at some point), and because in many places around the world it is legally required to make websites digitally accessible, accessibility should be thought about in the same way as performance- a necessity for any web-based product. 
+
+Additionally, it causes less churn to decide to implement basic accessibility considerations at the start of the project, than trying to add it on later or pivoting mid-project. Semantic HTML doesn't take any additional time to write than non-semantic markup, provides a lower cognitive burden for development, typically produces less markup which will help an application be more performant, and is better for SEO. 
+
+
+## Accessibility Strategy
+
+Digital accessibility regulations vary from country to country, but most at least point to the [WAI-ARIA](https://www.w3.org/WAI/) specification for compliance. 
+
+"100% accessible"- what does that mean? From a practical perspective, accessibility really looks more like 90% coding to the spec and 10% filing browser bugs (or keeping track of existing browser bugs). Keep in mind that if a workaround for a browser bug is implemented, an internal tracking issue in the product backlog should be also filed so as to provide the reminder to follow up on browser bugs at a later date. 
+
+Creating a sensible plan for your product up front can save a great deal of stress down the road. 

guides/v6.6.0/accessibility/learning-resources.md

@@ -0,0 +1,31 @@
+These accessibility learning resources will provide additional support to the developer looking to improve the quality of the code they write. 
+
+- [MDN Web Docs: Accessibility](https://developer.mozilla.org/en-US/docs/Learn/Accessibility)
+- [Using ARIA:](https://www.w3.org/TR/using-aria/) a practical guide for developers on how to add accessibility information to HTML elements
+- [Web Content Accessibility Guidelines(WCAG) 2.1](https://www.w3.org/TR/WCAG21/)
+- [Accessible Rich Internet Applications (ARIA) 1.1](https://www.w3.org/TR/wai-aria-1.1/) 
+- [How to meet WCAG (Quick Reference)](https://www.w3.org/WAI/WCAG21/quickref/)
+
+
+## Practical Resources
+
+- [Accessibility Insights](https://accessibilityinsights.io/)- Use FastPass to find common, high-impact issues 
+- [aXe extension for Chrome](https://chrome.google.com/webstore/detail/axe/lhdoppojpmngadmnindnejefpokejbdd)
+- [Accessibility Support](https://a11ysupport.io/)- Find out if your code will work with assistive tech
+- [How and where to report accessibility bugs](https://www.digitala11y.com/how-where-to-report-accessibility-bugs/)
+
+
+### Design 
+
+- [ColorSafe](http://colorsafe.co/)- Empowering designers with beautiful and accessible color palettes based on WCAG Guidelines of text and background contrast ratios
+- [Accessible Color Palette Builder](https://toolness.github.io/accessible-color-matrix/)
+
+
+### Writing
+
+- [Plain Language](https://plainlanguage.gov/) - Learn how to write in a way that makes it easier for people to read and understand. 
+
+
+### Other Useful Articles
+
+- [The difference between keyboard and screen reader navigation](https://tink.uk/the-difference-between-keyboard-and-screen-reader-navigation/)