Add A11y Mascots to Accessibility Index

guides/release/accessibility/index.md

@@ -1,5 +1,7 @@
 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. 

guides/v3.12.0/accessibility/index.md

@@ -1,5 +1,7 @@
 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. 

guides/v3.13.0/accessibility/index.md

@@ -1,5 +1,7 @@
 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. 

guides/v3.14.0/accessibility/index.md

@@ -1,5 +1,7 @@
 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. 

guides/v3.15.0/accessibility/index.md

@@ -1,5 +1,7 @@
 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. 

guides/v3.16.0/accessibility/index.md

@@ -1,5 +1,7 @@
 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. 

guides/v3.17.0/accessibility/index.md

@@ -1,5 +1,7 @@
 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. 

guides/v3.18.0/accessibility/index.md

@@ -1,5 +1,7 @@
 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.