Merge pull request ember-learn#563 from rwjblue/lint-markdown

Lint markdown in CI (and fix linting issues).

Author: MelSumner

.local.dic

@@ -27,6 +27,7 @@ Ctrl-C
 customizations
 D3
 dasherize
+DataAdapter
 datepicker
 de
 debounce
@@ -36,6 +37,7 @@ deserializing
 draggable
 durations
 enumerables
+ember-a11y
 ember-cli-deprecation-workflow
 ember-cli-cjs-transform
 ember-cli-mirage.
@@ -46,13 +48,15 @@ erroring
 Evented
 facto
 falsy
+focusable
 frontend
 fullname
 geocode
 geocoding
 Geolocation
 globbing
 *google
+HammerJS
 hardcode
 hashchange
 Hoc
@@ -74,6 +78,8 @@ modularity
 naïve
 nav
 *NPM
+NVDA
+Orca
 Param
 param
 params
@@ -88,6 +94,7 @@ prepend
 pre-transition
 readme
 readonly
+recognizers
 relayout
 repo
 rerender
@@ -108,12 +115,18 @@ subexpression
 suboptimal
 substate
 substates
+syntaxes
+TalkBack
 teardown
 templating
 todo
 todos
 typeahead
+UIs
 unsilence
 untrusted
 usecase
-viewport
+viewport
+VoiceOver
+WAI-ARIA
+WCAG

.travis.yml

@@ -29,4 +29,5 @@ before_install:
 script:
   - npm run lint:hbs
   - npm run lint:js
+  - npm run lint:md
   - npm test

guides/release/reference/accessibility-guide.md

@@ -67,9 +67,9 @@ Here is a checklist of some things to keep in mind when developing your applicat
   - All interactive elements must be usable with only a keyboard. A helpful development tip- make sure you can use your own app just using your keyboard.
   - Do not use `role="presentation"` or `aria-hidden="true"` on a focusable element.
   - All interactive elements must have an accessible name.
-- The values for the role attribute are pre-defined by the ARIA specification. This is not something an author can define a custom value for (that is not listed in the spec). [Learn more about roles in the specification.](https://www.w3.org/TR/wai-aria/#roles_categorization)
+- The values for the role attribute are predefined by the ARIA specification. This is not something an author can define a custom value for (that is not listed in the spec). [Learn more about roles in the specification.](https://www.w3.org/TR/wai-aria/#roles_categorization)
 - In general, avoid making your own keyboard shortcuts. [Screen readers already provide quite a few.](https://dequeuniversity.com/screenreaders/) There is some nuance here, so proceed with caution should you choose to do so. 
-- "Completely accessible" may be somewhat of a misnomer. Practical accessibility 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 you choose to implement a workaround for a browser bug, you will need to to put an issue in your product backlog to follow up on browser bugs at a later date. 
+- "Completely accessible" may be somewhat of a misnomer. Practical accessibility 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 you choose to implement a workaround for a browser bug, you will need to put an issue in your product backlog to follow up on browser bugs at a later date.
 
 ### Focus
 

guides/v3.7.0/reference/accessibility-guide.md

@@ -67,9 +67,9 @@ Here is a checklist of some things to keep in mind when developing your applicat
   - All interactive elements must be usable with only a keyboard. A helpful development tip- make sure you can use your own app just using your keyboard.
   - Do not use `role="presentation"` or `aria-hidden="true"` on a focusable element.
   - All interactive elements must have an accessible name.
-- The values for the role attribute are pre-defined by the ARIA specification. This is not something an author can define a custom value for (that is not listed in the spec). [Learn more about roles in the specification.](https://www.w3.org/TR/wai-aria/#roles_categorization)
+- The values for the role attribute are predefined by the ARIA specification. This is not something an author can define a custom value for (that is not listed in the spec). [Learn more about roles in the specification.](https://www.w3.org/TR/wai-aria/#roles_categorization)
 - In general, avoid making your own keyboard shortcuts. [Screen readers already provide quite a few.](https://dequeuniversity.com/screenreaders/) There is some nuance here, so proceed with caution should you choose to do so. 
-- "Completely accessible" may be somewhat of a misnomer. Practical accessibility 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 you choose to implement a workaround for a browser bug, you will need to to put an issue in your product backlog to follow up on browser bugs at a later date. 
+- "Completely accessible" may be somewhat of a misnomer. Practical accessibility 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 you choose to implement a workaround for a browser bug, you will need to put an issue in your product backlog to follow up on browser bugs at a later date.
 
 ### Focus