Version française de la présentation "Massively Maintained Accessibility", par Joe Dolson: http://www.slideshare.net/joedolson/massively-maintained-accessibility-wordpress Support de la présentation faite au 21ème Séminaire Technique AccessiWeb: http://inova.snv.jussieu.fr/evenements/colloques/colloques/index.php?c=87 Sujet: On estime que 24% des sites Web sont administrés via WordPress. Permettre de contribuer de manière accessible avec cet outil est donc un enjeu majeur. Joe Dolson, "Mr WordPress Accessibility", décrit comment le développement de WordPress intègre cette exigence, les stratégies qui fonctionnent, et comment participer à ce mouvement.

1. L’accessibilité à
grande échelle
Comment WordPress intègre l’accessibilité à
son processus de développement

2. Le véritable auteur
Joe Dolson
“Mr WordPress Accessibility”
www.joedolson.com
@joedolson

3. Ses contributions
Contributeur du core, et de Make WordPress
Accessible
Développeur de thèmes.
Plugs-in:
• WordPress Accessibility
• Access Monitor
• et d’autres

4. La présentation d’origine
Sur Slideshare:
http://www.slideshare.net/joedolson/massively-
maintained-accessibility-wordpress

5. Petit voyage dans le temps
Mars 2011:
- Création de
Make.WordPress.org/accessibility
Mai 2011:
- Première demande a11y: WP 3.2 et thème
Twenty Eleven.

6. Suite du voyage dans le temps
De mai à novembre 2011:
...

7. Monter une organisation
- Leadership
- Implication
- Processus

8. Le processus d’évolution de
WordPress
● Proposer une amélioration, un correction, ou
une fonctionnalité.
● Obtenir l’adhésion d’autres
développeurs.
● Fournir un feedback sur les anomalies.
● Arrive ce qui doit arriver...
● Intégrer au core.

9. Le processus d’évolution de
WordPress
● Release Lead: définit les priorités, oriente
les développement.
● Impliquer le release lead est vital.
Un grand merci à Drew Jaynes, release lead
sur WordPress 4.2, pour avoir priorisé
l’accessibilité.

10. L’Accessibilité implique de
s’impliquer...
● Aujourd’hui: 326 tickets actifs
● Nécessite un dialogue
● Nécessite une implication très tôt.
● Nécessite des gens qui fournissent des
correctifs
● Nécessite des gens qui ont accès à la
gestion deTrac (bug tracker de WP)

11. Combien de contributeurs?
Par release:
3.8: 188 3.9: 267 4.0: 275 4.1: 283
Des centaines de contributeurs et des
centaines de correctifs = nombreuses
opportunités d’introduire des problèmes
d’accessibilité... Ou des solutions.

12. Informer, former les dév WP
- Conférences aux WordCamp
- Articles sur make.wordpress.org et ailleurs
- Des ressources (code)
- Formations en ligne
- Implication active dans le suivi des tickets
dans Trac

13. Stratégies efficaces
- Être spécifique: et pas “WordPress ne suit
pas le standard”.
https://core.trac.wordpress.org/ticket/29955
- Prioriser:
https://make.wordpress.org/core/2015/02/23/
this-week-in-4-2-february-23-march-1/
- Suivre

14. Adhésion des développeurs du core
Succès total.
(Ce qui ne veut pas dire que tout le monde est
d’accord sur tout.)

15. Où en est-on?
- Le groupe de tests est géré par Rian
Rietveld
- https://make.wordpress.org/accessibility/testing/
- Deux fois par release, établissement d’une
liste des priorités
(les transverses d’abord, les intégrables à la beta
ensuite)

16. Où en est-on?
- Demandes de consultation de la part de
l’équipe de développement du core, l’équipe
UX, et les développeurs de plug-ins de
fonctionnalités.
- Bibliothèque de modèles accessibles
(WordPress accessibility pattern library)
- Tests et formations sur l’accessibilité des
thèmes

17. Stratégie à long terme
● Evolution lente mais continue
● 3 releases par an avec des itérations
individuelles.
● Création de bibliothèques de soltions
(#31368: Let WP Speak, WP pattern library)
et formation/information des développeurs.

18. Rétrocompatibilité
- Gérer la compatibilité de l’API pour 36,000
plugins and 3,000 themes a de nombreuses
implications:
- API de paramétrage
- Fonctions et widgets hérités d’anciennes versions
- Utilisation de classes CSS “pour lecteurs d’écran”
- Comportement des formulaires
- Dans le l’Admin, titres de sections et structure HTML

19. A l’avenir
Avancées majeures dans le futur:
- JSON REST API
- https://wordpress.org/plugins/json-rest-api/
- Image Flow
Menaces et opportunités...

20. Quel est le CMS le plus accessible?
Drupal

21. Quel est le CMS le plus accessible?
Est-ce que les sites réalisés avec Drupal sont
accessibles, et ceux avec WordPress ne le
sont pas?
Non. Ni l’un, ni l’autre.

22. L’impact des choix
- Exemple: les formulaires
- WordPress: pas de module de création de
formulaire dans le core
- Drupal: oui oui, on a.
- Les choix du développeur s’imposent
toujours par rapport au comportement du
core. Partout.

23. Les CMS produisent du HTML
Le HTML (valide) est accessible.
JavaScript, CSS, le HTML invalide, les
contenus inaccessibles mettent la pagaille.

24. Pister une anomalie dans WordPress
Le Core.
Le Plug-in.
Le Thème.
Hey. Qui a bousillé ce site?

25. Pister une anomalie dans WordPress
Si c’est dans l’admin (back-office) :
Probablement dans le core.
Sauf si c’est la page de paramétrage d’un
thème ou d’un plug-in...

26. Coté front?
- menu ou rendu de l’article? Probablement le
thème.
- Dans un formulaire de contact, une
fonctionnalité particulière type calendrier ou
service eCommerce: c’est un plug-in...
Pister une anomalie dans WordPress

27. Pister une anomalie dans WordPress
Les thèmes sur WordPress.org doivent suivre
des règles:
https://make.wordpress.org/themes/handbook/review/
...sauf pour les thèmes commerciaux. Les
thèmes commerciaux ont leurs propres ‘règles’.

28. Signaler des anomalies dans WordPress
Les anomalies sur le Core devraient être
reportées ici:
https://core.trac.wordpress.org/newticket
Avant de reporter quoique ce soit, tester avec
tous les plug-ins désactivés, et avec le thème
par défaut...

29. Merci!
Joseph Dolson
http://www.joedolson.com/
joe@joedolson.com
@joedolson
Olivier Nourry
http://accessiblog.fr
@OlivierNourry