C'est bien parce que certains titres sont là pour l'accroche qu'il y a parfois des second titres. A une époque révolue, on utilisait des titres à rallonge.
Aussi, ayant séparé la forme du contenu, les contenus contextuels, les métadonnées, il reste la structure du document qui porte la donnée.
Cette structure standardisée peut désormais être facilement manipulée et reconstruite à l'infini.
L'argument revenant souvent dans ces colonnes, qui veut que le CSS et le JavaScript se justifient par l'accessibilité, est valable, mais pas dans le cas d'un contenu distribué à un ensemble hétérogène d'individus et de lecteurs (n'oublions pas les robots et autres spiders qui viennent apporter une plus-value démesurée à la distribution du contenu).
Le maître d'oeuvre du site web ne peut savoir à qui il s'adresse précisément, à moins de faire le choix de restreindre son audience. Aussi, il a tout à perdre à chercher à développer pour une audience spécifique, et tout à gagner à coder pour le plus grand nombre. Ce qui peut se faire en suivant les standards du W3C, et tenant compte des exceptions de sociétés commerciales (je pense à Apple ou Microsoft), en rendant ces exception lisses. C'est à dire qu'elles n'interfèrent pas avec les standards, qu'elles ne rendent ni le code inutilisable pour le standard, ni plus complexe à développer pour s'accrocher à des détails qui devraient rester secondaires.
Le maître d'oeuvre n'a pas à s'occuper de l'accès par son audience de façon technique, ou plus exactement, la meilleure façon d'en tenir compte, est de suivre les normes qui prennent déjà en charge ces contraintes techniques, et évitent de les réinventer. Il n'a pas non plus à se soucier de pallier à des contraintes de navigateurs, c'est le travail de l'architecte du navigateur.
Dès lors, ce que l'on appelle la lourdeur du respect des normes, devient un moyen de glisser sur les difficultés et de s'en détacher, pour se concentrer sur l'essentiel, par exemple d'autres modèles de contraintes permettant de transporter et distribuer plus de données, de façon plus efficace, comme par l'audio, la video, la transcription, la traduction et la description des contenus.
Peut-être aussi transformer de coûteuses heures de travail qualifié de développement applicatifs non pérennes, et de surcroît limitants, en la contribution ou le financement d'API modèles, ou la prise en charge sérieuse des contraintes liées à l'accessibilité des données.
Un exemple simple est d'opérer un suivi des accès en erreur (fallback), et d'y remédier par l'action plutôt que par le déni.
Comme par exemple rechercher la raison d'un lien cassé, plutôt que d'attendre de l'utilisateur qu'il effectue lui-même ces recherches.
Ces recherches alourdissent la charge de travail de l'utilisateur, celle des services qu'il utilisera pour ce faire, gonflant la bande passante inutilement, etc... Dès lors que l'on sait l'utilisateur (l'audience), de par des demandes récurrentes, mesuré généralement avec plusieurs zéros, a tendance à se augmenter et se à multiplier.
Cette l'audience est elle-même créatrice de diffusion, et la toile (web) en marche se constitue naturellement. Pour se convaincre de la redondance des requêtes et des contenus, il suffit de lancer une recherche sur Google, qui vous proposera plusieurs requêtes déjà effectuées, et bon nombre de résultats.
Aussi la correction de ces erreurs, la recherche et la résolution des problèmes, ne peut qu'avoir l'effet d'un cercle vertueux. Bien plus efficace que le développement de codes censés apporter de l'accessibilité (sur des détails) tout en nuisant à celle-ci (en général). Ne serait-ce que pour le respect de liens partenaires venant gratuitement augmenter votre visibilité.
Le développement JavaScript pour l'accessibilité, doit ainsi se comprendre dans le respect des standards, par l'agglomération de codes réutilisables, API ou briques de développement, mais de façon systématiquement détachée du contenu auquel il s'applique, pour qu'il ne devienne pas un carcan dont on serait fier.
Il vaut mieux construire des développements sains sur une base saine, et obtenir de la valeur ajoutée avec un code propre, servi par une gestion efficace des ressources.
[^] # KISS : faire simple, faire accessible
Posté par Patrick Trauquesègues . En réponse au journal #spaghettis xhtml standard, sauce javascript. Évalué à 0.
C'est bien parce que certains titres sont là pour l'accroche qu'il y a parfois des second titres. A une époque révolue, on utilisait des titres à rallonge.
Aussi, ayant séparé la forme du contenu, les contenus contextuels, les métadonnées, il reste la structure du document qui porte la donnée.
Cette structure standardisée peut désormais être facilement manipulée et reconstruite à l'infini.
L'argument revenant souvent dans ces colonnes, qui veut que le CSS et le JavaScript se justifient par l'accessibilité, est valable, mais pas dans le cas d'un contenu distribué à un ensemble hétérogène d'individus et de lecteurs (n'oublions pas les robots et autres spiders qui viennent apporter une plus-value démesurée à la distribution du contenu).
Le maître d'oeuvre du site web ne peut savoir à qui il s'adresse précisément, à moins de faire le choix de restreindre son audience. Aussi, il a tout à perdre à chercher à développer pour une audience spécifique, et tout à gagner à coder pour le plus grand nombre. Ce qui peut se faire en suivant les standards du W3C, et tenant compte des exceptions de sociétés commerciales (je pense à Apple ou Microsoft), en rendant ces exception lisses. C'est à dire qu'elles n'interfèrent pas avec les standards, qu'elles ne rendent ni le code inutilisable pour le standard, ni plus complexe à développer pour s'accrocher à des détails qui devraient rester secondaires.
Le maître d'oeuvre n'a pas à s'occuper de l'accès par son audience de façon technique, ou plus exactement, la meilleure façon d'en tenir compte, est de suivre les normes qui prennent déjà en charge ces contraintes techniques, et évitent de les réinventer. Il n'a pas non plus à se soucier de pallier à des contraintes de navigateurs, c'est le travail de l'architecte du navigateur.
Dès lors, ce que l'on appelle la lourdeur du respect des normes, devient un moyen de glisser sur les difficultés et de s'en détacher, pour se concentrer sur l'essentiel, par exemple d'autres modèles de contraintes permettant de transporter et distribuer plus de données, de façon plus efficace, comme par l'audio, la video, la transcription, la traduction et la description des contenus.
Peut-être aussi transformer de coûteuses heures de travail qualifié de développement applicatifs non pérennes, et de surcroît limitants, en la contribution ou le financement d'API modèles, ou la prise en charge sérieuse des contraintes liées à l'accessibilité des données.
Un exemple simple est d'opérer un suivi des accès en erreur (fallback), et d'y remédier par l'action plutôt que par le déni.
Comme par exemple rechercher la raison d'un lien cassé, plutôt que d'attendre de l'utilisateur qu'il effectue lui-même ces recherches.
Ces recherches alourdissent la charge de travail de l'utilisateur, celle des services qu'il utilisera pour ce faire, gonflant la bande passante inutilement, etc... Dès lors que l'on sait l'utilisateur (l'audience), de par des demandes récurrentes, mesuré généralement avec plusieurs zéros, a tendance à se augmenter et se à multiplier.
Cette l'audience est elle-même créatrice de diffusion, et la toile (web) en marche se constitue naturellement. Pour se convaincre de la redondance des requêtes et des contenus, il suffit de lancer une recherche sur Google, qui vous proposera plusieurs requêtes déjà effectuées, et bon nombre de résultats.
Aussi la correction de ces erreurs, la recherche et la résolution des problèmes, ne peut qu'avoir l'effet d'un cercle vertueux. Bien plus efficace que le développement de codes censés apporter de l'accessibilité (sur des détails) tout en nuisant à celle-ci (en général). Ne serait-ce que pour le respect de liens partenaires venant gratuitement augmenter votre visibilité.
Le développement JavaScript pour l'accessibilité, doit ainsi se comprendre dans le respect des standards, par l'agglomération de codes réutilisables, API ou briques de développement, mais de façon systématiquement détachée du contenu auquel il s'applique, pour qu'il ne devienne pas un carcan dont on serait fier.
Il vaut mieux construire des développements sains sur une base saine, et obtenir de la valeur ajoutée avec un code propre, servi par une gestion efficace des ressources.