La spécification dit :

«L'élément article représente un ensemble complet , ou composition autonome dans un document, une page, une application ou un site et qui est, en principe, distribuable ou réutilisable indépendamment, par exemple en syndication. Il peut s'agir d'un article de forum, d'un article de magazine ou de journal, d'une entrée de blog, d'un commentaire soumis par l'utilisateur, d'un widget ou gadget interactif, ou de tout autre élément de contenu indépendant. serait un élément

enveloppant une série d'éléments

un pour chaque article de blog. Vous utiliseriez la même structure pour une liste de vidéos (pensez YouTube) avec chaque vidéo enveloppée dans un

une liste de produits (pensez Amazon) et ainsi de suite. Chacun de ces

est conceptuellement syndicable – chacun peut être autonome sur sa propre page dédiée, dans une annonce sur une autre page, en tant qu'entrée dans un flux RSS, etc.

WatchOS d'Apple contient Reader qui utilise le

élément pour connaître le contenu principal de votre page. Apple dit :

«Nous avons amené Reader à watchOS 5 où il s'active automatiquement lorsqu'il suit des liens vers des pages Web contenant du texte. Il est important de vous assurer que Reader extrait les éléments clés de votre page Web en utilisant le balisage sémantique pour renforcer la signification et la finalité des éléments du document. Voyons un exemple. Premièrement, nous indiquons quelles parties de la page sont les plus importantes en l'enveloppant dans une balise d'article. »

La combinaison de

avec des microdonnées HTML5 aide Reader à construire l'affichage optimal pour les petits écrans de montre: [19659012] «Plus précisément, si vous enfermez ces éléments d'en-tête dans l'article, assurez-vous qu'ils apparaissent tous dans Reader. Reader stylise également chaque élément d'en-tête différemment en fonction de la valeur de son attribut itemprop. En utilisant itemprop, nous pouvons nous assurer que l'auteur, la date de publication, le titre et le sous-titre figurent bien en évidence. »

Alors qu'en est-il de

?

Mon conseil habituel continue: ne vous embêtez pas avec [19659004] ou vous inquiétez de la différence avec

. Il a été inventé comme un wrapper générique pour les titres afin que le navigateur puisse déterminer le contour du document HTML5.

Le quoi? L'algorithme de contour de document est un moyen d'utiliser une seule balise de titre –

– et de le faire «magiquement» devenir le bon niveau de titre (par exemple, transformer en

etc.), selon la façon dont profondément il est imbriqué dans les éléments de sectionnement HTML5:

etc.

Donc, par exemple, voici ce que vous avez tapé dans votre CMS:

 Mon article fabuleux 

 Lorem Ipsum Trondant Fnord 

Cela fonctionne brillamment lorsqu'il est présenté comme un article autonome. Mais qu'en est-il de votre page d'accueil, qui est une liste de vos derniers articles?

 Mes derniers articles 



  
 Mon fabuleux article 

 
 Lorem Ipsum Trondant Fnord 





  
 Un autre magnum opus 

  
 Magnum solero paddlepop 

Dans cet exemple, selon la spécification, les éléments

à l'intérieur des éléments

«deviennent» logiques

car

comme

est un élément de sectionnement .

Note : Ce n'est pas une nouvelle idée. En 1991, Sir Oncle Timbo a écrit :

«Je préférerais en fait, au lieu de

etc. que les rubriques [those come from the AAP DTD] aient un emboîtable

… et un élément générique … qui, à n'importe quel niveau des sections, produirait le niveau de titre requis. "

Malheureusement, cependant, non le navigateur implémente HTML5 décrivant il est donc inutile d'utiliser

. À un moment donné, le lecteur d'écran JAWS a tenté d'implémenter l'algorithme de description de document (dans IE, mais pas sur Firefox) mais l'a implémenté de manière boguée . Il semble que les développeurs de navigateurs ne soient tout simplement pas intéressés (plus de détails sordides dans la section Lectures complémentaires pour les vrais anoraks).

"Mais," intervint un autre ami dans la conversation, "maintenant les navigateurs affichent des tailles différentes de police en fonction de la profondeur dans laquelle le

est imbriqué dans

s », et a procédé à le prouver. À couper le souffle!

Voici une démo similaire . La colonne de gauche montre quatre

imbriqués en sections; la colonne de droite montre un,

sans imbrication. La capture d'écran de Firefox montre que la valeur par défaut imbriquée de

est la même police que les balises

…

traditionnelles:

Grand aperçu )

Les résultats sont les mêmes dans Chrome, dérivés du chrome tels que Edge beta pour Mac et Safari sur Mac.

Cela signifie-t-il donc que nous devrions tous commencer à utiliser

comme notre seul élément de titre, en l'emboîtant dans

s?

Non. Parce que ce n'est qu'un changement dans le style visuel des h1. Si nous ouvrons l'inspecteur d'accessibilité de Firefox dans devtools, nous pouvons voir que le texte "niveau 2" est conçu pour ressembler à un H2, mais est toujours défini sur "niveau 1" – l'arborescence d'accessibilité n'a pas été modifiée pour être de niveau 2.

Comparez cela avec le Real H2 dans la colonne de droite:

Cela montre que l'arbre d'accessibilité a été correctement informé qu'il s'agit d'un titre de niveau 2. En fait, Mozilla a essayé de communiquer le niveau calculé à l'arbre d'accessibilité:

«Nous avons expérimenté un peu avec ça … mais nous avons dû y revenir parce que les membres de notre équipe a11y se plaignaient de trop de régressions (abaissement accidentel des niveaux

et autres). »

Pour les utilisateurs de technologies d'assistance, une bonne hiérarchie des rubriques est vitale. Comme le montre le huitième sondage auprès des utilisateurs de lecteurs d'écran WebAIM

«L'utilité de structures de titres appropriées est très élevée, 86,1% des répondants trouvant les niveaux de titres très ou assez utiles.»

Par conséquent, vous devriez continuer à utiliser

jusqu'à

et ignorer la section .

Never Say Never

"Mais .." vous pourriez maintenant bafouiller avec indignation, "il y a un droit d'élément

sur cette même page! ”. Et vous auriez raison, cher lecteur. Le «résumé rapide» est enveloppé dans un

pour des raisons d'accessibilité. Lorsque l'utilisateur de lecteur d'écran Léonie Watson a donné son webinaire " Comment un utilisateur de lecteur d'écran accède au Web ", elle a souligné un domaine où le balisage de Smashing Magazine pourrait être modifié pour améliorer son expérience.

Comme vous pouvez voir la capture d'écran, les articles Smashing sont précédés d'un résumé rapide, suivi d'une ligne horizontale séparant le résumé de l'article proprement dit.

Mais le séparateur est purement décoratif, donc Léonie ne pouvait pas dire où se terminait le résumé et où l'article commençait. Elle a suggéré une solution: nous avons enveloppé le résumé dans un élément

:

     Texte du résumé

Dans la plupart des lecteurs d'écran, un élément

n'est annoncé que s'il a un nom accessible . Dans ce cas, le texte de l'étiquette aria. Maintenant, son lecteur d'écran a annoncé «Quick summary region», et après le résumé «Quick summary region end». Ce balisage simple permet également à un utilisateur de lecteur d'écran de sauter le résumé s'il le souhaite.

Nous aurions pu utiliser un simple

mais ensuite, comme Marco Zehe écrit [19659012] «En règle générale, si vous étiquetez quelque chose via aria-label ou aria-labelledby, assurez-vous qu'il a un widget ou un rôle de repère approprié.»

Donc, plutôt que d'utiliser

nous avons choisi

comme qui a un rôle intégré de région et la loi infaillible de Bruce ARIA ™ s'applique: battements intégrés boulonnés.

Conclusion

Avec un peu de chance, vous êtes reparti avec ces plats à emporter:

• N'utilisez pas des charges de
  
  s. Faites de
  l'en-tête principal de votre page, puis utilisez
  etc. dans une hiérarchie appropriée sans ignorer les niveaux.
• 
  
  peut être utilisé avec aria-label pour signaler à un utilisateur de lecteur d'écran où une sous-partie particulière d'un article commence et se termine. Sinon, oubliez-le ou utilisez un autre élément, comme ou
  .
• 
  
  et sont très utiles pour les utilisateurs de lecteurs d'écran, et entièrement transparents pour ceux qui n'utilisez pas de technologie d'assistance. Alors utilisez-les.
• 
  
  n'est pas seulement pour les articles de blog – c'est pour tout ce qui est autonome. Cela aide également WatchOS à afficher correctement votre contenu.

Je remercie chaleureusement Léonie Watson de l'aide apportée à la rédaction de cet article. Toute erreur est entièrement de sa faute.

Lectures complémentaires

• " Rubriques et sections ", HTML 5.2
Recommandation du W3C (14 déc. '17)
Notez son avertissement: «Il n'y a actuellement aucune implémentation native connue de l'algorithme de plan… Par conséquent, l'algorithme de plan ne peut pas être utilisé pour transmettre la structure du document aux utilisateurs. Les auteurs doivent utiliser le rang de titre (h1-h6) pour transmettre la structure du document. »
• « Il n'y a pas d'algorithme de description de document », Adrian Roselli
Tous les détails sanglants de la façon dont la spécification
• « ARIA en HTML », W3C Editor's Draft (19 déc. '19)
Règles à suivre si vous vous retrouvez ajout de rôles et d'attributs ARIA au HTML.
• La valeur pratique du HTML sémantique », Bruce Lawson
Mon propre article, établissant un lien vers des détails sur la façon dont WatchOS utilise HTML5 et les microdonnées. [19659136] Éditorial fracassant « /> (ra, il)

Le meilleur outil 2023 pour ta croissance Instagram !

Source link

Partager :

• Cliquez pour partager sur Twitter(ouvre dans une nouvelle fenêtre)
• Cliquez pour partager sur Facebook(ouvre dans une nouvelle fenêtre)