-
Notifications
You must be signed in to change notification settings - Fork 0
/
index.html
293 lines (276 loc) · 15.5 KB
/
index.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
<!DOCTYPE html>
<html lang="fr">
<head>
<meta charset="UTF-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<meta http-equiv="X-UA-Compatible" content="ie=edge">
<title>Refcard Accessibilité</title>
</head>
<body>
<header>
<img src="./octo-logo.webp" alt=""/>
<p lang="en">Quick reference card</p>
<ul>
<li>
<a href="https://octo.com">octo.com</a>
</li>
<li>
<a href="https://blog.octo.com">blog.octo.com</a>
</li>
</ul>
<p lang="en">There is a better way</p>
</header>
<h1>Web <span lang="en"><abbr title="accessibility">a11y</abbr></span> pour tout le monde</h1>
<h2>Multiples contextes d'usage</h2>
<ul aria-label="Contextes d'usages">
<li>
<ul aria-label="Contextes d'usage connus">
<li>
écran + clavier + souris
</li>
</ul>
</li>
<li>
<ul aria-label="Contextes d'usage méconnus">
<li>synthèse vocale</li>
<li>liseuse <abbr title="noir et blanc">N/B</abbr></li>
<li>afficheur braille</li>
<li>assistant vocal</li>
</ul>
</li>
</ul>
<h3>Définition de l'accessibilité web</h3>
<figure>
<blockquote>
Mettre le web et ses services à la disposition de tous les individus, <strong>quels que soient</strong>
<ul>
<li>leur matériel ou logiciel</li>
<li>leur infrastructure réseau</li>
<li>leur langue maternelle, leur culture</li>
<li>leur localisation géographique</li>
<li>ou leurs aptitudes physiques ou mentales</li>
</ul>
</blockquote>
<figcaption>
Sir Timothy John Berners-Lee, Directeur du <abbr lang="en" title="World Wide Web Consortium">W3C</abbr>,
inventeur du <abbr lang="en" title="World Wide Web">WWW</abbr>
</figcaption>
</figure>
<h2>Concevoir pour tout le monde</h2>
<h3><strong>Étudier la diversité</strong> pour réduire l'exclusion.</h3>
<p>Qui sont vos utilisateurs et utilisatrices dans leur diversité ?
Assez difficile de savoir exactement, parce que c'est intraçable, mais ce qui est certain, c'est que parmi elleux, certain·es sont en situation de handicap avec :
</p>
<ul>
<li>troubles dys (10 % de la population) ;</li>
<li>déficience visuelle (3 %), daltoniens (4 %) ;</li>
<li>difficultés auditives (11,5 %) ;</li>
<li>difficultés difficultés motrices des membres supérieurs, etc.</li>
</ul>
<p>C'est sans compter les situations de handicap temporaire (bras dans le plâtre, dépression, etc.),
situationnel (lieu bruyant, contexte stressant, etc.)
ou liées à l'équipement non optimal (écran mal calibré, souris cassée, etc.).
</p>
<p>
<strong>20 à 40 %</strong> des internautes ont un accès difficile, partiel ou impossible aux informations et services en ligne.
</p>
<p>Questions à se poser en User Research :</p>
<ol>
<li>Qui sont mes utilisateurs et utilisatrices ? Et qui en est exclu ?</li>
<li>Quels sont leurs usages, dans leur diversité ?</li>
<li>Quelles sont leurs aides techniques (synthèse vocale, etc.) ?</li>
<li>Quels sont leurs besoins spécifiques ?</li>
<li>Vos personas reflètent-ils cette diversité ?</li>
</ol>
<a href="https://design-accessible.fr/" target="_blank" rel="noopener noreferrer">Designer un web accessible et inclusif (lien externe)</a>
<h3>Concevoir pour un cas d'usage extrême puis étendre au plus grand nombre.</h3>
<p>
Par exemple :
Lisa, aveugle, navigue à l'aide d'une synthèse vocale.
En conception, des textes alternatifs sont donc prévus pour être vocalisés à la place des images.
Ce qui sert aussi à Andréa qui navigue sans image, dans le train, où le débit est trop faible pour les afficher.
Concevoir pour un persona aveugle élargit l'usage pour tous les cas où les images ne s'affichent pas, etc.
</p>
<h2>Normes & lois</h2>
<ol>
<li> <img src="/iso.webp" alt="">
<a href="https://www.w3.org/WAI/standards-guidelines/fr" target="_blank" rel="noreferrer">
<span lang="en"><abbr>WCAG</abbr> Web content Accessibility Guidelines</span>
</a>
Norme ISO / EIC 40500
<time datetime="1999">1999</time>
</li>
<li> <img src="/europeenne.webp" alt=""> EN 301549
Norme européenne d'accessibilité
<time datetime="2014">2014</time>
</li>
<li>
<ul>
<li> <img src="/web.webp" alt="">
<a href="https://accessibilite.numerique.gouv.fr/" target="_blank" rel="noreferrer">
<abbr>RGAA</abbr>
</a>
Référentiel Général d'Amélioration de l'Accessibilité
<time datetime="2009">2009</time>
</li>
<li> <img src="/mobile.webp" alt="">
<a href="https://accessibilite.public.lu/fr/raam1/index.html" target="_blank" rel="noreferrer">
<abbr>RAAM</abbr>
</a>
Référentiel d'évaluation de l'Accessibilité des Applications Mobiles
<time datetime="2021">2021</time>
</li>
</ul>
</li>
</ol>
<h3>Ce que dit la loi</h3>
<p>La majorité des législations à travers le monde a adopté la norme <abbr title="Web Content Accessibility Guidelines" lang="en">WCAG</abbr> comme
référence. La directive européenne <abbr title="European Accessibility Act" lang="en">EAA</abbr> établit l’obligation d’accessibilité.</p>
<p>Trois échéances en France :</p>
<ol>
<li>Juillet 2021 tous les sites publics français</li>
<li>À partir du 28 juin 2025 tous les nouveaux produits<a href="#note-produits-numerique" aria-label="note complémentaire" aria-describedby="note-produits-numerique"><abbr title="note complémentaire">*</abbr></a></li>
<li>Juin 2030 tous les produits numériques<a href="#note-produits-numerique" aria-label="note complémentaire" aria-describedby="note-produits-numerique"><abbr title="note complémentaire">*</abbr></a></li>
</ol>
<p id="note-produits-numerique"><abbr title="note complémentaire">*</abbr>Sites internet, intranet, extranet, app mobiles, progiciel (web ou mobile) et mobilier urbain numérique de service
public et des entreprises privées fournissants des produits et services qui sont vendus ou utilisés au sein de l’UE,
quel que soit l’endroit où les entreprises sont basées, y compris livres numériques, services bancaires et billetteries de transport.</p>
<h2>Travail d'équipe</h2>
<figure>
<figcaption>Répartition des critères d'accessibilité selon les compétences nécessaires à leur réussite.</figcaption>
<ul>
<li>
61% Développement front
<a href="#define-html"><abbr lang="en" title="HyperText Markup Language">HTML</abbr></a> /
<a href="#define-js"><abbr lang="en" title="JavaScript">JS</abbr></a> /
<a href="#define-aria"><abbr lang="en" title="Accessible Rich Internet Application">ARIA</abbr></a>
</li>
<li>
26% Contenus (textes, images, graphiques, PDF, vidéos, transcripts, …)
</li>
<li>
13% Design
(<abbr lang="en" title="User Experience">UX</abbr> +
<abbr lang="en" title="User Interface">UI</abbr>)
inclusif et accessible
</li>
</ul>
<img src="/donut.webp" alt=""/>
</figure>
<p>Tous les profils sont concernés. C'est un travail d'équipe sous la houlette des <abbr lang="en" title="Product Owners">PO</abbr>.</p>
<h3>
Les rôles clés
<small id="competences-clef-a11y-web">Les compétences clés pour l'accessibilité web</small>
</h3>
<ul aria-describedby="competences-clef-a11y-web">
<li>
<strong>Designer</strong> formé·e au design inclusif et accessible
</li>
<li>
<strong>Dev <span lang="en">Front</span></strong> maîtrisant
<a href="#define-html"><abbr lang="en" title="HyperText Markup Language">HTML</abbr></a> /
<a href="#define-js"><abbr lang="en" title="JavaScript">JS</abbr></a> /
<a href="#define-aria"><abbr lang="en" title="Accessible Rich Internet Application">ARIA</abbr></a>
</li>
<li>
<strong lang="en">Product Owner</strong>
sachant prioriser et recetter l'accessibilité
</li>
<li>
<strong>Référent·e accessibilité</strong>
pilote l'application de la politique d'accessibilité
</li>
<li>
<strong>Rédacteurs/trices</strong>
formé·es à la production accessible de contenus
</li>
<li>
<strong>Auditeur/trice expert·e</strong>
pour établir la conformité
</li>
</ul>
<h2><span lang="en">Stack</span> Technique</h2>
<p>
L'accessibilité web repose sur le langage <abbr lang="en" title="HyperText Markup Language">HTML</abbr> auquel peuvent s'ajouter les langages <abbr lang="en" title="Cascading Style Sheet">CSS</abbr>, JavaScript et une touche d'<abbr lang="en" title="(Accessible Rich Internet Applications)">ARIA</abbr>.
</p>
<ol>
<li>
<strong>Le <dfn id="define-html"><abbr lang="en" title="HyperText Markup Language">HTML</abbr></dfn> structure l'information.</strong>
Ses balises apportent la sémantique : un bouton n'est pas un lien, qui n'est pas une <code><div></code>. Chaque composant <abbr lang="en" title="HyperText Markup Language">HTML</abbr> embarque nativement les comportements d'interaction attendus, de façon accessible : un <code><button></code> est déjà actionnable au clavier.
</li>
<li>
<strong>Le <dfn id="define-css"><abbr lang="en" title="Cascading Style Sheet">CSS</abbr></dfn> met en forme l'information</strong> présente dans le <abbr lang="en" title="HyperText Markup Language">HTML</abbr> de la page.
L'usage du <abbr lang="en" title="Cascading Style Sheet">CSS</abbr> uniquement ne rendra pas accessible l'information à tout le monde.
</li>
<li>
<strong>Le <dfn id="define-js">JavaScript</dfn> régit les interactions complexes,</strong> comme l'affichage de notifications ou une carte interactive.
Dans la plupart des cas, il ne sera pas nécessaire.
Il permet de coder des composants au-delà de ce qui est disponible en <abbr lang="en" title="HyperText Markup Language">HTML</abbr>.
</li>
<li>
<p>
<strong><dfn id="define-aria" lang="en"><abbr>ARIA</abbr> (Accessible Rich Internet Applications)</dfn></strong> propose un ensemble d'attributs qui étendent le <abbr lang="en" title="HyperText Markup Language">HTML</abbr>.
Il donne <strong>plus d'information aux technologies d'assistance</strong> :
</p>
<ul>
<li>en explicitant les liens entre les éléments, par exemple l'image et sa description;</li>
<li>en explicitant l'état d'un élément, par exemple la sélection en cours dans une liste;</li>
<li>en étendant la sémantique, par exemple un onglet fait d'un composant <code><button></code> sera enrichi par le <code>role="tab"</code></li>
</ul>
<p>
À utiliser avec parcimonie : <strong>pas d'attribut <abbr lang="en" title="Accessible Rich Internet Application">ARIA</abbr> vaut mieux qu'un attribut <abbr lang="en" title="Accessible Rich Internet Application">ARIA</abbr> mal renseigné.</strong>
</p>
</li>
</ol>
<img src="pyramid-tech.webp"
alt="L'accessibilité se repose avant tout sur le HTML, puis le CSS, le Javascript et enfin ARIA">
<h2>Comment vérifier ?</h2>
<img src="outils.webp"
alt="">
<p>Une partie des tests d'accessibilité est automatisable. Il existe pour cela de nombreux outils comme
<a href="https://wave.webaim.org/extension/" target="_blank" rel="noreferrer">WAVE</a>,
<a href="https://www.deque.com/axe/" target="_blank" rel="noreferrer">aXe</a>,
<a href="https://www.tanaguru.com/" target="_blank" rel="noreferrer">Tanaguru</a> ou
<a href="https://asqatasun.org/" target="_blank" rel="noreferrer">Asqatasun</a>. Mettre en place des tests auto est le point de départ.
</p>
<img src="mains.webp"
alt="">
<p>La majorité des tests d’accessibilité sont fonctionnels.
Ils s’effectuent par une inspection manuelle. Certains ne nécessitent pas de compétences techniques et
sont très faciles à réaliser en <a href="https://www.w3.org/WAI/test-evaluate/preliminary/" target="_blank" rel="noreferrer">10 « <span lang="en">Easy checks</span> »</a> : il s’agit de simuler des situations
réelles d’usage, en navigant par exemple sans image, sans
couleur, sans souris, etc.</p>
<aside>
<img src="tab.webp" alt="">
<h3>Exemple: naviguer au clavier</h3>
<p>Vérifiez que le produit web reste entièrement utilisable
sans souris ni <span lang="en">trackpad</span>, c'est-à-dire en utilisant
uniquement
les touches du clavier : <kbd>tab</kbd> , <kbd lang="en">enter</kbd>…</p>
<ol>
<li>Le déplacement doit être <strong>visible</strong> ;</li>
<li>et se dérouler dans un ordre <strong>logique</strong>;</li>
<li>Tout élément qui déclenche une action au clic ou au
survol (liens, boutons, champs de formulaires, menus
déroulants, vidéo, <span lang="en">datepicker</span>, etc.) doit être <strong>atteignable</strong> et <strong>actionnable</strong> au clavier seulement.</li>
</ol>
<p>Ils et elles vous remercieront : les personnes ayant des difficultés
motrices, celleux utilisant un lecteur d'écran (aveugles, dyslexiques...). La navigation
au clavier est un quotidien pour des <strong>milliers d’internautes</strong>.</p>
</aside>
<p>La pratique <strong>régulière</strong> de ces tests permet de maintenir un bon niveau d'accessibilité. Ils précédent l'audit qui établit le taux de conformité atteint (à planifier une fois par an). Il est bienvenu de les compléter par des tests avec lecteur d'écran puis par tests d'utilisabilité avec des personnes en situation de handicap.</p>
<footer>
<p>On ne <strong>corrige pas</strong> l'accessibilité, on <strong>fabrique</strong> accessible.</p>
<img src="" alt="OCTO Technology, Part of Accenture" lang="en">
<p>
© OCTO Technology 2024 -
<a
target="_blank"
rel="noopener noreferrer"
href="https://creativecommons.org/licenses/by-sa/4.0/">
Licence <abbr title="Creative Commons, attribution, share alike" lang="en">CC BY-SA</abbr> <img src="" alt=""><img src="" alt=""><img src="" alt="">
</a>
</p>
</footer>
</body>
</html>