Réponse en bref
Accepter un site Web est quelques heures de vérification par liste, pas une impression de la page d'accueil. Commencez sur un téléphone par des données mobiles, suivez les formulaires jusqu'au destinataire, lancez le WCAG 2.2 vous-même et envoyez une liste de…
Acceptation du site en bref
L'acceptation est une vérification structurée du site fini par rapport à ce que vous avez commandé, effectué avant le paiement final et avant que vous signez quelque chose. Cela prend quelques heures et il s'en va d'une liste écrite, pas de votre impression de la page d'accueil.
L'ordre est important: un téléphone sur une connexion faible d'abord, puis le contenu de page contre le mémoire, puis forme tout le chemin vers le destinataire, puis le WCAG 2.2 vérifie, puis la navigation, le comportement de chargement et le panneau d'administration. Tout ce que vous trouvez va dans un seul document.
L'acceptation ne consiste pas à attribuer la faute. Son but est de produire un enregistrement écrit de ce qui fonctionne et ce qui doit être corrigé, et de confirmer que le disque s'inscrit à l'intérieur des tours de révision votre paquet inclut réellement, plutôt que de les renverser.
Ce qui suit est douze blocs de contrôles. Chacun peut être fait sans outillage spécial: vous avez besoin d'un téléphone, d'un ordinateur portable, d'un navigateur et d'une heure où personne ne vous interrompt avec des questions sur quelque chose de complètement différent.
Que préparer avant de commencer à tester
Avant le premier clic, rassemblez trois documents : le bref ou le cahier des charges, la liste des pages et des caractéristiques de portée, et les courriels où les changements ont été convenus à mi-projet. Sans eux, la revue se transforme en une conversation sur le goût.
Demandez l'adresse exacte que vous examinez. Ce peut être un domaine de mise en scène ou le live, mais il doit être la même adresse pour vous et pour le développeur, ou vous finirez par discuter de deux versions différentes d'une page.
Préparez deux appareils : votre téléphone ordinaire et un ordinateur portable. Ne pas examiner seulement sur la machine de travail avec Internet bureau rapide et un grand moniteur, parce qu'il montre le site dans des conditions que vos visiteurs ne peuvent jamais avoir réellement.
Ouvrez une table vide avec ces colonnes : page, ce qui s'est passé, ce que vous attendiez, périphérique et navigateur, priorité. Vous y écrivez pendant que vous allez, plutôt que d'essayer de reconstruire le libellé d'une faute deux jours plus tard de la mémoire.
Commencez par un téléphone, sur une connexion lente
Ouvrez le site sur votre téléphone avant de l'ouvrir sur l'ordinateur portable. Les défauts de disposition qui restent invisibles sur un grand écran deviennent évidents sur un étroit, et vous voulez les rencontrer maintenant plutôt que dans un message d'un client.
Éteignez le Wi-Fi et naviguez sur le réseau mobile, idéalement quelque part où le signal est pauvre. C'est là que l'internet rapide du bureau cesse de cacher des choses : l'attente avant le premier texte lisible, la mise en page qui saute, les images qui arrivent en dernier.
Sur le téléphone, vérifiez trois choses : si le texte s'adapte sans défilement latéral, si votre pouce se pose sur des boutons et des liens, et si un en-tête collant ou une bannière de consentement couvre la même chose pour laquelle un visiteur est venu à la page.
La documentation sur les performances du MDN couvre aussi bien les performances perçues que la vitesse de chargement brute — la réaction de l'interface. Ce sentiment est exactement ce que vous testez lorsque vous ouvrez le site sur un téléphone dans la rue plutôt que sur le bureau d'un développeur.
Contrôle du contenu : le mémoire en regard de la page publiée
Prenez la liste des pages du brief et marchez-la ligne par ligne. Chaque page promise doit exister, s'ouvrir à partir d'un lien direct, et porter le bloc pour lequel elle a été commandée, plutôt qu'un paragraphe de placeholder de texte de remplissage laissé dans la construction.
Lisez la copie pour les typos, les prix dépassés, le nom d'une autre entreprise et les données de démonstration restantes. Il faut se rappeler ici : VITON13 n'écrit pas le contenu ou les traductions du client, de sorte que la copie vient de vous et relecture elle reste votre responsabilité.
Vérifiez les coordonnées partout où elles apparaissent : en-tête, pied de page, page de contact, données structurées et le message affiché après l'envoi d'un formulaire. Un mauvais chiffre dans un numéro de téléphone vous coûte discrètement les appels qu'il était censé apporter.
Regardez les images séparément: des produits corrects, pas de filigranes de stock, orientation correspondant à la mise en page. Vérifiez également leur texte alternatif — sous WCAG 2.2, critère de succès 1.1.1 Contenu non textuel, au niveau A.
Formulaires fin à fin : vers le destinataire, pas vers le bouton
Un formulaire est accepté lorsque l'enquête parvient à la personne qui y répond, et non lorsque le bouton répond à un clic. Tester jusqu'à ce que le bouton signifie accepter la moitié d'une fonctionnalité et entendre l'autre moitié d'un client que vous avez déjà perdu.
Envoyez une demande de test avec des détails réels et suivez tout le chemin: l'écran de remerciement, l'e-mail à la boîte de réception de l'entreprise, l'e-mail au client, et l'enregistrement dans le CRM ou la feuille de calcul si cela était dans la portée. Logez chaque étape comme sa propre ligne.
Puis cassez le formulaire à dessein : soumettez-le vide, tapez des lettres dans le champ du téléphone, utilisez une adresse sans signe, joignez un fichier trop grand. Les messages d'erreur doivent être texte à côté du champ et indiquer ce qui doit changer.
Dans WCAG 2.2, il s'agit de 3.3.1 Identification des erreurs et 3.3.2 Étiquettes ou instructions au niveau A, plus 3.3.3 Suggestion d'erreur au niveau AA. Une bordure rouge et le mot Erreur, avec rien d'autre à côté, ne les satisfait pas.
Accessibilité : WCAG 2.2 contrôle vous-même
WCAG 2.2 est une recommandation W3C comportant trois niveaux de conformité : A, AA et AAA. Si votre contrat ne mentionne aucun niveau, travaillez à l'AA et notez qu'une part importante de ses critères peut être vérifiée à la main, sans vérificateur et sans outillage payant.
Le contraste du texte selon le critère 1.4.3 au niveau AA est de 4,5:1 pour le texte ordinaire et de 3:1 pour le texte volumineux. Les bordures de champ, les icônes et les contrôles d'interface relèvent plutôt du critère 1.4.11, où le seuil est de 3:1.
Critère 2.5.8 Taille de cible (minimum) au niveau AA, ajouté dans la version 2.2, demande une zone cible d'au moins 24 par 24 pixels CSS, sous réserve des exceptions qu'il énumère. Regardez les petites icônes dans le pied de page et les flèches dans n'importe quelle galerie.
Deux autres ajouts dans 2.2 appartiennent à un examen de formulaire : 3.3.7 Entrée redondante au niveau A, en vertu de laquelle les informations déjà saisies dans le même processus ne devraient pas être à nouveau demandées sans raison, et 3.3.8 Authentification accessible au niveau AA si le site a une connexion.
Clavier, focus et zoom
Enlevez votre main de la souris et passez à travers la page d'accueil avec la touche Tab. Vous devriez voir où se trouve le focus à tout moment, l'ordre doit correspondre à l'ordre visuel, et les menus, modales et joueurs doivent tous vous libérer à nouveau.
Ce sont les critères 2.1.1 Clavier et 2.1.2 Aucun trait de clavier au niveau A, plus 2.4.7 Focus visible au niveau AA. Version 2.2 ajouté 2.4.11 Focus non masqué (minimum) au niveau AA, qui vaut la peine d'être testé contre les en-têtes collants et les barres de cookies.
Zoom d'essai : porter le texte à 200 %, puisque le critère 1.4.4 au niveau AA exige que le contenu et les fonctions restent utilisables. Ensuite, limitez la fenêtre du navigateur à environ 320 pixels CSS et confirmez qu'aucun défilement horizontal n'est apparu.
Si l'interface consiste à glisser — réarranger les cartes, un curseur de portée, une zone de dépôt de fichiers — le critère 2.5.7 au niveau AA demande une alternative à un seul pointeur qui ne nécessite pas de glisser, à moins que le glisser soit essentiel à la tâche elle-même.
Navigation, liens et états d'erreur
Marchez chaque élément de menu et chaque lien de pied de page. Chacun doit conduire à une page qui existe sur ce site, pas à un brouillon, pas au propre domaine du développeur, et pas à une page que vous avez demandé à avoir supprimé il y a plusieurs semaines.
Saisissez une adresse que vous connaissez n'existe pas. Vous devriez obtenir une page 404 dans la conception propre du site, avec le menu et un itinéraire de retour à la page d'accueil, plutôt qu'un message de serveur ou un écran blanc avec une chaîne technique sur elle.
Vérifiez les états vides : une recherche sans allumettes, un panier sans rien dedans, un catalogue filtré à zéro résultat. Dans chaque cas, un visiteur doit comprendre ce qui s'est passé et ce qu'il peut faire ensuite.
Regardez aussi la plomberie : le titre de l'onglet navigateur devrait différer par page et la décrire — critère 2.4.2 au niveau A — et la langue de la page devrait être déclarée, critère 3.1.1 au même niveau.
Vitesse et comportement de chargement
La vitesse est jugée sur le même téléphone et le même réseau, pas dans un rapport produit dans des conditions idéales. Ouvrez le site à partir d'un démarrage froid sans données stockées et regardez combien de temps il faut pour que le premier texte lisible apparaisse.
Surveillez les changements de disposition. Si le texte est déjà lisible et qu'une image ou une bannière tardive la pousse vers le bas de l'écran, c'est un défaut d'acceptation et non une écurie. Des changements comme ça causent des erreurs et font perdre aux gens leur place dans le texte.
Les outils de développeur de navigateur comprennent le throttling réseau qui simule une connexion lente. La documentation de performance du MDN fait valoir que la réactivité du chargement et de l'interface vaut la peine d'être mesurée, plutôt qu'un numéro de gros plan seul.
Ne pas exiger une note particulière dans un outil tiers si aucune note n'a été inscrite au contrat. Phrase plutôt la constatation comme comportement: sur un téléphone sur les données mobiles, le premier écran apparaît nettement plus tard que sur l'ordinateur portable. Cela peut être vérifié.
Le panneau d'administration: pouvez-vous modifier sans casser quoi que ce soit
Connectez-vous avec votre propre compte plutôt que celui du développeur. Confirmez que vous avez le rôle de propriétaire ou d'administrateur et que vous pouvez voir chaque section qui a été discutée comme quelque chose que vous pourriez éditer vous-même après le lancement.
Faire une vraie modification : modifier une rubrique sur une page, ajouter un paragraphe, télécharger une image, enregistrer et regarder la version publique. Si un développeur est nécessaire pour cela, cette partie du travail n'a pas encore été acceptée.
Vérifiez que l'édition ne brise pas la mise en page : un long cap devrait s'envelopper plutôt que d'échapper à son bloc, et une image d'une taille non planifiée devrait encore s'adapter. Coller un très long mot et un très long paragraphe sur le but et regarder à nouveau.
Acceptez la limite. Les modifications de contenu sont les vôtres; les modèles et les modifications logiques appartiennent au développeur. Dans le cadre de l'appui continu à 290 $/mois, le volume de ces travaux est convenu au début de chaque cycle.
Écrire la liste des défauts et l'insérer dans les rondes de révision
Envoyez un message avec une liste, pas dix messages par jour. Chaque élément nomme la page, l'appareil, ce qui s'est passé et ce que vous attendiez, et porte une capture d'écran dans la mesure du possible. Une note disant qu'il semble hors revient tout droit comme une question.
Divisez la liste en deux : les choses qui arrêtent l'utilisation du site, et les choses que vous préférez maintenant différemment. Les premiers sont des défauts, les seconds sont de nouvelles demandes, et ils atterrissent différemment sur le calendrier et les révisions payées.
Le nombre de rondes dépend de l'emballage et ne passe pas d'un à l'autre. Le site de lancement à 380 $, avec un échéancier de 3 à 5 jours ouvrables, comprend 2 rondes avant le lancement. Produit Build à $880, sur 2-3 semaines, comprend 2 rondes par fonction livrée.
Site Fix Pack à 70 $, en 1-2 jours ouvrables, est 1 tour et jusqu'à cinq correctifs convenus, avec une vérification mobile et de bureau et une liste avant/après au transfert. Lancement du site Express à 520 $, en 2 jours ouvrables, est 1 tour après la première construction complète.
Sign-off et ce qui se passe après l'acceptation
Signez lorsque les articles de votre liste sont fermés et revérifiés sur le même téléphone que vous avez commencé. Le deuxième passage prend beaucoup moins de temps que le premier, car d'ici là vous connaissez déjà la route à travers le site.
Mettez par écrit ce qui reste en dehors de l'œuvre : contenu et traductions, si ceux-ci sont assis à vos côtés par accord, ou applications mobiles natives et licence de paiement, qui ne font pas partie de Product Build.
Décidez ce qui arrive au site suivant. Corrections ponctuelles après le lancement Fix Pack Site, tandis que les mises à jour prioritaires, un rythme de sortie hebdomadaire et la maintenance technique appartiennent à En continu Dev Support à 290 $/mo, facturé sur un cycle mensuel avec un préavis de 30 jours pour s'arrêter.
Alors gardez la liste de contrôle elle-même. En six mois, lorsque vous acceptez le prochain travail ou le changement de fournisseur, un itinéraire que vous avez déjà marché vous sauve une soirée et règle l'argument sur ce qui compte comme terminé.
Checklist pratique
- Ouvrez le site sur votre propre téléphone sur les données mobiles plutôt que le bureau Wi-Fi.
- Promenez la liste des pages dans le dossier et marquez tout ce qui manque ou qui reste un détenteur de place.
- Envoyez une demande de test et suivez-la à la boîte de réception de l'entreprise, au client et au CRM.
- Onglet sur la page d'accueil et confirmez que le focus reste visible et que les modales libèrent le clavier.
- Vérifier le contraste de texte et les tailles cibles par rapport aux critères 1.4.3, 1.4.11 et 2.5.8.
- Recueillir chaque découverte dans une table hiérarchisée et l'envoyer en un seul message.
Questions et réponses
Combien de temps devrait prendre l'acceptation du site Web?
Prévoyez quelques heures de travail ininterrompu plutôt que de regarder rapidement. Le temps passe à marcher une liste écrite à partir d'un téléphone et d'un ordinateur portable, en envoyant des demandes de test et en enregistrant ce que vous trouvez. Le diviser en deux séances est très bien; envoyer vos conclusions comme dix messages distincts ne l'est pas.
Quel appareil dois-je commencer ?
Votre propre téléphone, sur les données mobiles plutôt que le bureau Wi-Fi. Un écran large avec Internet rapide cache des failles de mise en page à écran étroit, des images arrivées tardives et l'attente avant l'apparition du premier texte lisible.
Combien de cycles de révision les paquets de développement incluent-ils?
Cela dépend du paquet et ne porte jamais de travers d'un à l'autre. Fix Pack site à 70 $, en 1-2 jours ouvrables, comprend 1 tour. Site de lancement à 380 $, en 3-5 jours ouvrables, comprend 2 rondes avant le lancement. Produit Build à $880, sur 2-3 semaines, comprend 2 rondes par fonction livrée. Lancement du site Express à 520 $, en 2 jours ouvrables, comprend 1 tour après la première construction complète.
Et si des problèmes apparaissent après que j'ai signé ?
Petites corrections précisément décrites correspondent au Pack de Fix Site à 70$: jusqu'à 5 corrections convenues en 1-2 jours ouvrables, avec une vérification mobile et de bureau et une liste avant/après au transfert. Il ne couvre pas les nouvelles pages, la refonte ou les migrations. Pour un rythme continu, En continu Dev Support à 290 $/mois fonctionne sur un cycle mensuel avec un préavis de 30 jours pour arrêter, et le volume de travail est convenu au début de chaque cycle.
Dois-je vraiment avoir besoin des vérifications d'accessibilité sur un petit site?
Les vérifications WCAG 2.2 énumérées ici n'ont pas besoin d'auditeur ni d'outils payants : contraste, commande de clavier, mise au point visible, taille de la cible et erreurs de forme claires. Ils capturent également des défauts d'utilisation ordinaires en cours de route, parce qu'un contrôle trop petit pour frapper et un message d'erreur sans explication se mettent en travers de tout le monde.