Je travaille en tant que développeur côté client chez The Guardian et, jusqu’à récemment, j’étais membre de l’équipe des abonnements. L’objectif de mon équipe était d’encourager les lecteurs à nous soutenir par le biais d’abonnements numériques.
Chez The Guardian, nous croyons qu’il est important de garder un journalisme de qualité gratuit et ouvert à tous. Cela signifie que nous devons souligner clairement à nos lecteurs pourquoi nous soutenir via un abonnement numérique est une bonne chose à faire et leur présenter les avantages.
Grâce à des recherches sur l’expérience utilisateur, nous avons testé des moyens d’expliquer les avantages d’un abonnement numérique et avons sélectionné les meilleures idées. Nous avons ensuite testé ces idées parallèlement à nos propres hypothèses à l’aide de tests A/B.
Une idée qui a le plus résonné chez nos participants à la recherche était un tableau de comparaison. Un tableau comparatif permet aux lecteurs de parcourir une série d’options de produits et de leur dire en un coup d’œil ce qu’elles incluent. Quelque chose un peu comme le tableau ci-dessous, qui compare les fonctionnalités d’une série de produits proposés par Shopify :
J’étais le développeur chargé de créer le composant de tableau de comparaison pour un test A/B. Le composant correspondait bien à mes compétences – un composant d’interface utilisateur avec un contenu non dynamique – donc j’ai pensé que le construire serait un jeu d’enfant. J’ai travaillé rapidement, en m’appuyant sur des outils dans ma zone de confort, comme flexbox. Dans mon esprit, les tableaux étaient obsolètes (spoiler : ils ne le sont pas), alors je les ai évités au profit d’une liste, me disant que du point de vue d’un lecteur d’écran, le contenu était à peu près une liste.
Mon premier point d’inflexion a été lorsque j’ai ouvert la page dans Safari – l’un de mes premiers contrôles de confiance pour m’assurer que mon code fonctionne dans les navigateurs que nous prenons en charge. Effectivement, il était cassé. J’ai soupiré, pensant que flexbox était le problème probable. J’ai décidé qu’il était temps d’être courageux et j’ai ouvert la feuille de triche de la grille CSS que j’avais mise en signet. L’implémentation des colonnes de grille CSS s’est avérée simple. Cela a juste fonctionné.
Where can I find open positions?
Apply for one of our open positions here.
What can I expect from the interview process?
We aim to be as fair and transparent as possible in our hiring process. Similar to other organisations, there is a CV screening, phone interview, coding exercise and a face to face interview. Read more about what to expect and apply now here.
-
","credit":"","pillar":0}"> Guide rapideComment rejoindre The Guardian Product & Engineering ?
Montrer
Où puis-je trouver des postes vacants ?
Postulez à l’un de nos postes ouverts ici.
Que puis-je attendre du processus d’entretien ?
Nous visons à être aussi équitables et transparents que possible dans notre processus d’embauche. Comme pour d’autres organisations, il y a une sélection de CV, un entretien téléphonique, un exercice de codage et un entretien en face à face. En savoir plus sur ce à quoi s’attendre et postuler maintenant ici.
–
Merci pour votre avis.
C’est à peu près à ce moment-là que j’ai commencé à m’interroger sur les meilleures pratiques pour les tables accessibles, et après avoir lu allié-101, j’ai réalisé que les tableaux ne sont en fait pas obsolètes – pas du tout. Si vous essayez de créer un tableau de données, c’est certainement le HTML sémantique correct à utiliser. J’ai donc timidement supprimé
- et l’ai remplacé par
et j’ai remplacé
- par
. Comme l’article l’a suggéré, j’ai utilisé scope = “column” et scope = “row” pour délimiter les en-têtes de colonne et de ligne, et j’ai ajouté un visuellement caché pour expliquer plus en détail le but du tableau aux utilisateurs de lecteurs d’écran.
-
Ne modifiez pas l’accessibilité : réfléchissez à la façon de rendre votre code accessible dès le départ.
-
Si vous essayez de créer une table de données, utilisez
-
Si vous utilisez
n’utilisez pas display: flex et n’utilisez pas display: grid. Ceux-ci briseront la sémantique de la table.
-
C’est le grand :ne créez pas une expérience distincte ou différente pour les personnes utilisant la technologie d’assistance. Les personnes utilisant des lecteurs d’écran peuvent naviguer et comprendre les tableaux si nous fournissons le code HTML, les attributs et les étiquettes corrects.
-
Lis les instructions.
Après avoir apporté ces modifications, je suis à nouveau passé à Safari et j’ai lancé VoiceOver. J’ai parcouru les en-têtes de page, puis j’ai utilisé la commande VoiceOver pour lire le contenu. À mon grand désarroi, VoiceOver est passé de l’en-tête avant mon tableau à l’en-tête après celui-ci. C’était comme si la table n’était pas là. Je l’ai cherché sur Google et j’ai essayé un certain nombre de choses différentes avant d’ajouter finalement role = “présentation”, et hop, VoiceOver a daigné le lire.
Je ressens le besoin de m’excuser à l’avance, car ce que je vais dire fera grincer des dents à certains lecteurs.
Je pensais que, comme un tableau est un élément intrinsèquement visuel, je devais réfléchir à la meilleure façon d’exprimer le contenu du tableau pour un lecteur d’écran. J’ai remplacé les données de la table avec label-aria et aria-caché, qui lit le contenu de la table sous forme de liste. J’ai ensuite mis mon code sur notre site de mise en scène afin que les gens puissent essayer l’élément avec un lecteur d’écran et l’ai posté sur notre chaîne d’accessibilité en demandant des commentaires.
Heureusement, les retours ont été aussi rapides que défavorables. Un de mes collègues a écrit “Je ne suis pas très enthousiaste à l’idée de… donner aux utilisateurs de lecteurs d’écran un type de contenu très différent, ou une impression différente de ce qui se trouve réellement sur la page… Je ne pense pas que nous devrions supprimer les outils par défaut que les lecteurs d’écran donnent aux utilisateurs. pour naviguer dans les tables comme ils préfèrent ». Elle a noté que j’avais effectivement masqué la “tableness” de la table en ajoutant role=”presentation” au HTML
. Elle a également souligné que les utilisateurs de lecteurs d’écran peuvent être malvoyants et peuvent être déconcertés par les expériences contradictoires présentées dans mon exemple.Un peu découragé, je suis retourné à mon code et j’ai soigneusement supprimé tous les aria-hidden = “true” et la plupart des instances de aria-label. J’ai ajouté un en-tête de colonne masqué visuellement appelé “avantages” pour la colonne d’en-tête de ligne. J’ai également approfondi mes connaissances sur commandes clavier pour naviguer dans un tableau. J’ai supprimé role=”presentation” de l’élément table mais, malgré tous mes efforts, je n’ai pas pu faire en sorte que VoiceOver lise le contenu de la table.
J’ai référé le problème à mon collègue qui avait fourni les commentaires. J’ai pensé que cela valait la peine qu’elle essaie, car le problème pourrait simplement être mes compétences en lecture d’écran un peu nulles. Je lui ai également envoyé le lien vers allié-101 pour expliquer le tableau HTML. Peu de temps après, elle est revenue vers moi. Elle remarqua qu’au fond de allié-101 il y avait une section “ne pas le faire” que j’avais manquée. Dit-elle: “C’est une grille CSS. Si vous supprimez ‘display: grid’… le tableau fonctionne bien et toutes les lignes et colonnes sont récupérées ». Donc, ma dernière erreur dans cette litanie était de ne pas avoir lu les instructions.
Peu de temps après, j’ai finalement intégré le code et le test A/B a été mis en ligne. Outre les apprentissages du lecteur et du produit lors du test, j’ai acquis des connaissances fondamentales sur l’accessibilité grâce à l’expérience de la création de ce composant. C’était un bon rappel que, aussi simple que puisse paraître le composant, il vaut toujours la peine de planifier à l’avance l’accessibilité. Cela permettrait une conversation initiale avec le concepteur pour discuter s’il peut y avoir des compromis potentiels à la conception. Plus important encore, j’ai appris un principe fondamental de l’accessibilité : ne créez pas une expérience distincte ou différente pour les personnes handicapées. Cela conduit à la ségrégation et à un contenu déroutant difficile à utiliser pour les gens.
Les apprentissages en résumé
Le développement de produits numériques est au cœur du Guardian. Vous pourriez créer les produits qui mettent en valeur notre journalisme progressiste et indépendant, concevoir les outils que les journalistes utilisent pour écrire leurs histoires, développer les services qui permettent à ces histoires d’être distribuées à travers le monde ou protéger notre avenir financier.
Si vous souhaitez rejoindre notre équipe de produits et d’ingénierie, veuillez visiter le Page des carrières de Guardian News & Media.
— to www.theguardian.com