n'oublions pas les robots et autres spiders qui viennent apporter une plus-value démesurée à la distribution du contenu
Quelle plus-value ? Le référencement ? Le HTML est fait pour présenter le contenu pour des humains (handicapés ou pas). C’est au concepteur du robot de s’adapter au format, pas au concepteur du site de s’en faire une contrainte.
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.
Pour l’audio et la vidéo ça a justement été normalisé par HTML5, suite à une longue période où effectivement ce n’était pas standard et pas du tout « accessible », typiquement, en Flash.
Pour ce qui est de la description du contenu et bien c’est à ça que servent mot-clés, description, et autres balises du header HTML, non ?
Il n'a pas non plus à se soucier de pallier à des contraintes de navigateurs
Le problème c’est qu’il n’y a pas un architecte du navigateur mais des architectes des navigateurs : Mozilla, MS, Google, pour citer les principaux. Il y a aussi des gens pour considérer que le contenu Web n’a pas forcément vocation à être exploité par un navigateur mais autrement, je pense à Weboob.
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.
Si on se retrouve avec un lien interne qui est cassé c’est clairement qu’on a fait de la merde en concevant son site. Par contre, pour les liens externes ça ne dépend évidemment pas du site. C’est le site pointé qui fait de la merde.
Dans ce cas, évidemment, le site peut détecter que le lien ne répond plus et agir en conséquence (ne pas présenter le lien au visiteur par exemple) mais ça c’est pallier les mauvais comportements des autres. Ce n’est pas forcément une bonne idée.
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.
Je dirais même que lorsque ta recherche est une question proprement formulée, on trouve quasiment toujours dans les résultats un site de Q&A où quelqu’un a déjà posé exactement la question que l’on se pose soi-même... et bien sûr quelqu’un y a répondu... :)
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.
À la lecture de tous tes commentaires et en particulier celui-là, j’ai l’impression que tu confonds contenu « documentaire », c’est à dire statique (ou à peine dynamique, jore un peu de JS pour trier les tableaux ou autre truc simple dans le genre) et contenu « applicatif », c’est à dire fortement dynamique, où le contenu envoyé par le serveur dépend fortement du contenu (formulaires typiquement) envoyé par le client.
Le code JS est exécuté par le client (on peut faire du code serveur en JS aussi mais je mettons ça de côté pour l’instant), donc visible de celui-ci, donc modifiable par celui-ci !
Le code serveur, lui, est au contraire connu seulement du « maître d’œuvre » comme tu dis... Même si ce code est libre et donc disponible pour tout un chacun, du point de vu du client on peut s’attendre à ce que n’importe quoi tourne...
détachée du contenu auquel il s'applique
Si le contenu de mon document est défini par : « un nombre au hasard entre 1 et 6 », le code JS qui tire un numéro au hasard ne fait-il pas partie du contenu ?
[^] # Re: KISS : faire simple, faire accessible
Posté par Marotte ⛧ . En réponse au journal #spaghettis xhtml standard, sauce javascript. Évalué à 2.
Quelle plus-value ? Le référencement ? Le HTML est fait pour présenter le contenu pour des humains (handicapés ou pas). C’est au concepteur du robot de s’adapter au format, pas au concepteur du site de s’en faire une contrainte.
Pour l’audio et la vidéo ça a justement été normalisé par HTML5, suite à une longue période où effectivement ce n’était pas standard et pas du tout « accessible », typiquement, en Flash.
Pour ce qui est de la description du contenu et bien c’est à ça que servent mot-clés, description, et autres balises du header HTML, non ?
On dit : « pallier des contraintes » https://fr.wiktionary.org/wiki/pallier
Le problème c’est qu’il n’y a pas un architecte du navigateur mais des architectes des navigateurs : Mozilla, MS, Google, pour citer les principaux. Il y a aussi des gens pour considérer que le contenu Web n’a pas forcément vocation à être exploité par un navigateur mais autrement, je pense à Weboob.
Si on se retrouve avec un lien interne qui est cassé c’est clairement qu’on a fait de la merde en concevant son site. Par contre, pour les liens externes ça ne dépend évidemment pas du site. C’est le site pointé qui fait de la merde.
Dans ce cas, évidemment, le site peut détecter que le lien ne répond plus et agir en conséquence (ne pas présenter le lien au visiteur par exemple) mais ça c’est pallier les mauvais comportements des autres. Ce n’est pas forcément une bonne idée.
Je dirais même que lorsque ta recherche est une question proprement formulée, on trouve quasiment toujours dans les résultats un site de Q&A où quelqu’un a déjà posé exactement la question que l’on se pose soi-même... et bien sûr quelqu’un y a répondu... :)
À la lecture de tous tes commentaires et en particulier celui-là, j’ai l’impression que tu confonds contenu « documentaire », c’est à dire statique (ou à peine dynamique, jore un peu de JS pour trier les tableaux ou autre truc simple dans le genre) et contenu « applicatif », c’est à dire fortement dynamique, où le contenu envoyé par le serveur dépend fortement du contenu (formulaires typiquement) envoyé par le client.
Le code JS est exécuté par le client (on peut faire du code serveur en JS aussi mais je mettons ça de côté pour l’instant), donc visible de celui-ci, donc modifiable par celui-ci !
Le code serveur, lui, est au contraire connu seulement du « maître d’œuvre » comme tu dis... Même si ce code est libre et donc disponible pour tout un chacun, du point de vu du client on peut s’attendre à ce que n’importe quoi tourne...
Si le contenu de mon document est défini par : « un nombre au hasard entre 1 et 6 », le code JS qui tire un numéro au hasard ne fait-il pas partie du contenu ?