alternative à Confort de lecture

[Nicolas Graner]

Olivier KEUL a écrit :

> La solution de Nicolas me semble une bonne initiative mais pourquoi
> un > outil d'accessibilité n'est-il pas lui-même accessible ?

Parce que je ne suis pas expert, mais toujours prêt à m'améliorer en
profitant de vos conseils !

> Sauf erreur de ma part, je ne vois pas la présence des « for » sur >
> les label et des « id » sur les input permettant de relier >
> l'intitulé au champ.

En effet, j'ai utilisé la syntaxe "simplifiée" du label dans laquelle
le label et l'input sont tous deux inclus dans la balise <label>. Je
n'ai appris que plus tard que cette syntaxe, bien que valide, est
déconseillée du point de vue de l'accessibilité. Et, comme je l'ai dit
précédemment, je n'ai pas retravaillé sur cette page depuis des
années. Ce sera facile à corriger.

> Deuxième remarque, toujours dans le cas d'une synthèse vocale,
> comment l'utilisateur aveugle ou non-voyant va-t-il savoir que le
> bleu ciel de la 3ème ligne correspond aux couleurs des liens non
> visités et pas à la couleur de fond par exemple ? il me semble qu'un
> tableau de données correctement réalisé ferait parfaitement
> l'affaire.

D'accord pour l'objection, mais je ne vois pas très bien ce que vous
voudriez mettre comme lignes et colonnes dans ce tableau. Je veux
surtout que le tout tienne dans la largeur de la fenêtre quelle que
soit la taille de la police utilisée (c'est le cas ici : les cases de
couleur sont juste à la suite l'une de l'autre, le retour à la ligne
se fait automatiquement comme pour du texte). Je crains qu'avec un
tableau on ne soit obligé de fixer le nombre de cases par ligne, en
perdant cette fluidité. Mais peut-être n'ai-je pas bien compris ce que
vous avez en tête.

Est-ce qu'il ne suffirait pas de mettre un "title" sur chaque input du
genre "bleu ciel pour liens non visités" ?

Nicolas