ember-learn · mansona · Sep 2, 2020 · Sep 1, 2020 · Sep 2, 2020
diff --git a/guides/v3.20.0/accessibility/application-considerations.md b/guides/v3.20.0/accessibility/application-considerations.md
@@ -0,0 +1,108 @@
+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 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>
+
+## Configurations
+
+### Application template wrapper
+
+You can simplify your markup and increase accessibility at the same time by configuring `application-template-wrapper`.
+
+If you are using the [application template wrapper](https://emberjs.com/blog/2018/02/16/ember-3-1-beta-released.html#toc_new-optional-feature-application-template-wrapper) enabled (default state), then you would need to add certain aria roles to your [landmark regions](https://www.w3.org/WAI/PF/aria/roles#landmark_roles), even if you are using native HTML elements, because those regions are not the direct child descendant of the body element (they are the children of the div that wraps the Ember app).
+
+If you disable the [application template wrapper](https://emberjs.com/blog/2018/02/16/ember-3-1-beta-released.html#toc_new-optional-feature-application-template-wrapper), you will not need to add role attributes to your landmark regions when they are the direct descendant of the body element, and they are using native HTML elements. This is the preferred approach for accessible applications.
+
+To disable this feature and improve your app's accessibility:
+
+```bash
+ember feature:disable application-template-wrapper
+```
+
+**Application Template Wrapper Disabled** _(preferred)_
+
+```hbs
+<body>
+  <header></header>
+  <main></main>
+  <footer></footer>
+</body>
+```
+
+**Application Template Wrapper Enabled**
+
+```hbs
+<body>
+  <div class="ember-view">
+    <header role="banner"></header>
+    <main role="main"></main>
+    <footer role="contentinfo"></footer>
+  </div>
+</body>
+```
+
+<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 learn more about landmark roles and how to use them: <a href="https://www.w3.org/WAI/PF/aria/roles#landmark_roles">https://www.w3.org/WAI/PF/aria/roles#landmark_roles</a>. Still need more help? Visit the #topic-a11y channel in <a href="https://emberjs.com/community/">the community chat</a>.
+      </div>
+    </div>
+    <img src="/images/mascots/zoey.png" role="presentation" alt="">
+  </div>
+</div>
+
+## Ember applications vs role=''application''
+
+An important thing to note in this section is this: "application" in Ember development and "application" in landmark roles have two _very_ different meanings. 
+
+The <abbr title="too long; didn't read">TL;DR</abbr>? Don't use `role="application"` until you have done your research and know exactly how it is to be used correctly (if at all). There are **very** few use cases where the role of application is appropriate.
+
+Read more about it: [https://www.a11yproject.com/posts/2013-02-09-how-to-use-application-role/](https://www.a11yproject.com/posts/2013-02-09-how-to-use-application-role/)
+
+## 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-gestures](https://github.com/html-next/ember-gestures) - Ember Gestures provides an easy way to use gestures by making it simple to define and use HammerJS managers and recognizers throughout your app.
+- [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/)
diff --git a/guides/v3.20.0/accessibility/components.md b/guides/v3.20.0/accessibility/components.md
@@ -0,0 +1,91 @@
+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>`, 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
+<label for="input-firstName">First Name:</label>
+<input id="input-firstName" name="firstName" value="" type="text" />
+```
+
+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>First Name:
+  <input name="firstName" 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>
diff --git a/guides/v3.20.0/accessibility/index.md b/guides/v3.20.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. 
diff --git a/guides/v3.20.0/accessibility/learning-resources.md b/guides/v3.20.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/)