Markdown fixes part 1 (fr/web/a*) (#4316)

* Fix MD038, no spaces inside code span elements

* Fix MD037, no spaces inside emphasis markers

* Fix MD039, no spaces inside link text

* Missed link text fix in API file

* Various typo fixes

5 files changed, 5 insertions, 5 deletions

diff --git a/files/fr/web/accessibility/an_overview_of_accessible_web_applications_and_widgets/index.md b/files/fr/web/accessibility/an_overview_of_accessible_web_applications_and_widgets/index.md
index 3789895ae7..6f169ef86e 100644
--- a/files/fr/web/accessibility/an_overview_of_accessible_web_applications_and_widgets/index.md
+++ b/files/fr/web/accessibility/an_overview_of_accessible_web_applications_and_widgets/index.md
@@ -187,7 +187,7 @@ Voici un résumé de la façon dont la navigation au clavier devrait fonctionner
 
 - En cas de doute, imitez le comportement standard du bureau du contrôle que vous créez.
 
-Ainsi, pour l’exemple de widget Tabs ci-dessus, l’utilisateur devrait être capable de naviguer dans le conteneur du widget (le \<ol> dans notre balisage) en utilisant les touches <kbd>Tab</kbd> et <kbd><kbd>Maj</kbd>+<kbd>Tab</kbd></kbd>. Une fois que le focus du clavier est à l’intérieur du conteneur, les touches fléchées devraient permettre à l’utilisateur de naviguer entre chaque onglet (les éléments \<li>). De là, les conventions varient d’une plateforme à l’autre. Sous Windows, l’onglet suivant doit être automatiquement activé lorsque l’utilisateur appuie sur les touches fléchées. Sous Mac OS X, l’utilisateur peut appuyer sur <kbd>Entrée</kbd> ou sur <kbd>Espace</kbd> pour activer l’onglet suivant. Un tutoriel en profondeur pour créer [Widget navigables grâce à des contrôles Javascript ](/fr/docs/Contr%C3%B4les_DHTML_personnalis%C3%A9s_navigables_au_clavier)comme décrit ici afin de montrer comment avoir ce comportement en JS.
+Ainsi, pour l'exemple de widget `Tabs` ci-dessus, l'utilisatrice ou l'utilisateur devrait être capable de naviguer dans le conteneur du widget (l'élément [`<ol>`](/fr/docs/Web/HTML/Element/ol) dans notre balisage) en utilisant les touches <kbd>Tab</kbd> et <kbd>Maj</kbd>+<kbd>Tab</kbd>. Une fois que le focus du clavier est à l'intérieur du conteneur, les touches fléchées devraient permettre à l'utilisatrice ou l'utilisateur de naviguer entre chaque onglet (les éléments [`<li>`](/fr/docs/Web/HTML/Element/li)). De là, les conventions varient d'une plateforme à l'autre. Sous Windows, l'onglet suivant doit être automatiquement activé lorsque l'utilisatrice ou l'utilisateur appuie sur les touches fléchées. Sous Mac OS X, on peut appuyer sur <kbd>Entrée</kbd> ou sur <kbd>Espace</kbd> pour activer l'onglet suivant. Un tutoriel en profondeur pour créer des [widgets navigables grâce à des contrôles JavaScript](/fr/docs/Web/Accessibility/Keyboard-navigable_JavaScript_widgets) comme décrit ici montre comment avoir ce comportement en JS.
 
 Pour plus de détails à propos de ces conventions de navigation au clavier, un aperçu ici [DHTML style guide](http://dev.aol.com/dhtml_style_guide) est disponible. Il délivre un aperçu de la façon dont la navigation au clavier devrait fonctionner pour chaque type de widget pris en charge par ARIA. Le W3C offre également un document utile [ARIA Best Practices](http://www.w3.org/WAI/PF/aria-practices/Overview.html) qui inclut la navigation au clavier et les raccourcis pour une variété de widgets.
 
diff --git a/files/fr/web/accessibility/aria/aria_live_regions/index.md b/files/fr/web/accessibility/aria/aria_live_regions/index.md
index 03a05a4387..65b9feb178 100644
--- a/files/fr/web/accessibility/aria/aria_live_regions/index.md
+++ b/files/fr/web/accessibility/aria/aria_live_regions/index.md
@@ -68,7 +68,7 @@ The Paciello Group propose des [informations sur l'état du support des zones "L
 - aria-labelledby :
   - : L’attribut `aria-labelledby=[LISTE_ID]` est utilisé pour associer un ou des libellés à une zone. Le fonctionnement est similaire à celui d'`aria-controls` mais les références d'id pointent vers les libellés associés aux blocs identifiés, et les références multiples sont également séparées par un espace.
 - aria-describedby :
-  - : L’attribut `aria-describedby=[LISTE_ID]` est utilisé pour associer une ou des descriptions à une zone. Le fonctionnement est similaire à celui d'`aria-controls `mais les références d'id pointent vers les textes descriptifs associés aux blocs identifiés, et les références multiples sont également séparées par un espace.
+  - : L'attribut `aria-describedby=[LISTE_ID]` est utilisé pour associer une ou des descriptions à une zone. Le fonctionnement est similaire à celui d'`aria-controls` mais les références d'identifiant pointent vers les textes descriptifs associés aux blocs identifiés, et les références multiples sont également séparées par un espace.
 
 ### Cas d’étude avancé : liste de contacts
 
diff --git a/files/fr/web/accessibility/aria/roles/button_role/index.md b/files/fr/web/accessibility/aria/roles/button_role/index.md
index 6a25a27938..888b543d16 100644
--- a/files/fr/web/accessibility/aria/roles/button_role/index.md
+++ b/files/fr/web/accessibility/aria/roles/button_role/index.md
@@ -68,7 +68,7 @@ Une fois le bouton activé, la gestion du focus dépendra du type d'action effec
 
 #### Gestionnaires d'évènements nécessaires
 
-Les boutons peuvent être manipulés avec une souris, le toucher et le clavier. Pour les éléments HTML natifs `<button>`, l'évènement `onclick` du bouton est déclenché lors du clic de la souris ou lorsque l'utilisateur utilise la touche <kbd>Espace</kbd> ou <kbd>Entrée</kbd> lorsque le bouton a le focus. Si un autre élément est utilisé pour créer un bouton, l'évènement `onclick `ne se déclenche qu'au clic de la souris, y compris lorsqu'on utilise `role="button"`. C'est pour cette raison qu'on doit ajouter des gestionnaires d'évènements distincts à l'élément afin de réagir aux appuis sur les touches <kbd>Espace</kbd> ou <kbd>Entrée</kbd>.
+Les boutons peuvent être manipulés avec une souris, le toucher et le clavier. Pour les éléments HTML natifs `<button>`, l'évènement `onclick` du bouton est déclenché lors du clic de la souris ou lorsque l'utilisatrice ou l'utilisateur utilise la touche <kbd>Espace</kbd> ou <kbd>Entrée</kbd> lorsque le bouton a le focus. Si un autre élément est utilisé pour créer un bouton, l'évènement `onclick` ne se déclenche qu'au clic de la souris, y compris lorsqu'on utilise `role="button"`. C'est pour cette raison qu'on doit ajouter des gestionnaires d'évènements distincts à l'élément afin de réagir aux appuis sur les touches <kbd>Espace</kbd> ou <kbd>Entrée</kbd>.
 
 - `onclick`
   - : Gère l'évènement déclenché lorsque le bouton est activé avec un clic de souris ou au toucher.
diff --git a/files/fr/web/accessibility/aria/roles/switch_role/index.md b/files/fr/web/accessibility/aria/roles/switch_role/index.md
index 1dd2f5d17e..d6d1e9a3b0 100644
--- a/files/fr/web/accessibility/aria/roles/switch_role/index.md
+++ b/files/fr/web/accessibility/aria/roles/switch_role/index.md
@@ -11,4 +11,4 @@ original_slug: Accessibilité/ARIA/Techniques_ARIA/Utilisation_du_groupe_switch
 ---
 Le rôle ARIA switch est très similaire au [role checkbox](/fr/docs/Accessibilit%C3%A9/ARIA/Techniques_ARIA/Utiliser_le_role_checkbox), à la sémantique près — il a deux états représentant on/off, au lieu de checked/unchecked.
 
-Extrait des [spec ARIA 1.1 ](http://rawgit.com/w3c/aria/master/aria/aria.html#switch): l'attribut `aria-checked` d'un `switch` indique si l'entrée est on (`true`) ou off (`false`). La valeur `mixed` n'est pas supportée, et les agents utilisateurs _DOIVENT_ la traiter comme équivalente à `false` pour ce rôle.
+Extrait des [spécifications ARIA 1.1](https://www.w3.org/TR/wai-aria-1.1/#switch)&nbsp;: l'attribut `aria-checked` d'un `switch` indique si l'entrée est activée (`true`) ou désactivée (`false`). La valeur `mixed` n'est pas supportée, et les agents utilisateurs _DOIVENT_ la traiter comme équivalente à `false` pour ce rôle.
diff --git a/files/fr/web/accessibility/understanding_wcag/index.md b/files/fr/web/accessibility/understanding_wcag/index.md
index 07b8abfe58..ba30a69747 100644
--- a/files/fr/web/accessibility/understanding_wcag/index.md
+++ b/files/fr/web/accessibility/understanding_wcag/index.md
@@ -13,7 +13,7 @@ Les WCAG 2.0 et 2.1 fournissent un ensemble détaillé de lignes directrices pou
 
 ## Les quatre principes
 
-Les WCAG sont globalement divisés en quatre principes — éléments majeurs que le contenu Web **doit être** pour être considéré comme accessible (voir [Comprendre les Quatre Principes d'Accessibilité ](https://www.w3.org/TR/UNDERSTANDING-WCAG20/intro.html#introduction-fourprincs-head)pour les définitons des WCAG).
+Les WCAG sont globalement divisés en quatre principes — éléments majeurs que le contenu web **doit être** pour être considéré comme accessible (voir [Comprendre les quatre principes d'accessibilité (en anglais)](https://www.w3.org/TR/UNDERSTANDING-WCAG20/intro.html#introduction-fourprincs-head) pour les définitions des WCAG).
 
 Chacun des liens ci-dessous vous mènera à des pages qui développent davantage ces domaines, vous donnant des conseils pratiques sur la façon de rédiger votre contenu Web afin qu'il soit conforme aux critères de succès décrits dans chacune des directives WCAG 2.0 et 2.1 qui se subdivisent davantage en chaque principe.