Gaëtan L. : notes en front-end: accessibilité

Affichage des articles dont le libellé est accessibilité. Afficher tous les articles

08 juin 2019

2-3 ans après

Retour à D3.js, étant sur le point d'achever une formation full-stack - en complément de mon expérience front-end.

Dans le même temps, un bug que j'avais signalé sur Bugzilla en février 2017, concernant un problème de rendu SVG sur Firefox (rendu en lien avec la taille des caractères ; bug de priorité 3), a trouvé ces jours-ci une solution.

Edit du 8 septembre :
en stage chez WebForce3, d'où je sors en tant qu'étudiant, j'approfondis ma pratique du JavaScript (principalement natif) ainsi que mes compétences dans la réalisation d'une interface en lien avec des données.
Bref, une bonne partie de ce que j'apprécie en front-end, tout en plongeant dans les arcanes du back. Last but not least, l'ambiance y est des meilleures.

21 juin 2014

Outils couleurs : pour des contrastes suffisamment accessibles

Les WCAG 2 fournissent une formule pour établir le ratio entre deux couleurs. La formule est exprimable en JavaScript.

Il est ainsi possible de déterminer, dans un spectre de couleurs complémentaires à une couleur précise, laquelle lui sera la plus fortement contrastée. Dans l'algorithme, ce spectre est paramétrable sur trois teintes :
- code générique ;
- interface pour 4913 couleurs à partir de 3 complémentaires.

Il l'est tout aussi facilement sur cinq teintes : interface pour 4913 couleurs à partir de 5 complémentaires.

En laissant la notion de complémentaire pour élargir la sélection à un spectre élargi à toutes les nuances : un outil pour obtenir une couleur contrastée renforcée.

PS : ce formulaire est désormais riche de fonctionnalités ARIA
- "Accessible Rich Internet Applications".

PPS : essais systématiques sur www.equatorium.net/e1/declinaisons, dont couleurs-contrastes-5 qui manifeste qu'il n'y a pas de corrélation directement proportionnelle entre le ratio et la valeur de luminance L du système HSL.

19 août 2013

Outil JavaScript : détecter l'activation des styles pour améliorer l'accessibilité et optimiser les scripts

…
var detectionCSS = false;
function detecterCSS(){
 var b = document.getElementsByTagName("body")[0];
 var x1 = b.offsetWidth;
 b.style.width = x1 - 1 + "px";
 var x2 = b.offsetWidth;
 b.style.width = "";
 detectionCSS = x1 == x2 ? false : true;
}
</script>
</head>
<body>
<script>
detecterCSS();
</script>

Récemment écrit pour un site de Sanofi - mais en XHTML 1 :
=> présent dans l'en-tête via l'appel d'un fichier 'techno-abilities.js', qui contient aussi Modernizr et l'ajout d'une classe 'js' - afin, réciproquement, de détecter l'activation du JavaScript pour les CSS.

La variable 'detectionCSS' est ensuite sollicitée dans les scripts qui sont appelés à la fin de 'body'.
Exemple : définir une fonction vide pour un carousel avec styles désactivés.

18 août 2013

Note CSS : unités accessibles pour font-size

Cf. article de Matthieu Bué : Font-size, Responsive et Accessibilité : le Bon, la Brute et le Truand » Webdesign Friday (#wdfr)

Elément body réglé à cinq huitièmes (62,5%) de 16px (réglage agent par défaut) càd élément body réglé à 10px obtenu au 'reset' par :
body {font-size: 62.5%}

L'unité 'em' est préférable à l'unité 'px' quand on tient compte d'utilisateurs accoutumés au maniement de vieux IE ;
et formellement aussi, de référentiels d'accessibilité
(et du gadget A⁺)
avec l'inconvénient de calculs pour compenser les héritages.

CSS3 résout la question de l'emboîtement avec l'unité 'rem' ('r' pour "root")
NB : non encore personnellement testé

En tentant a priori 'rem' CSS3 avec compatibilité IE7-8 :
h2{font-size: 2.2em; font-size: 2.2rem;}
comment traiter théoriquement les niveaux intermédiaires ?
- si l'on y évite 'font-size', quelle utilité alors pour 'rem' ?
- sinon multiplication des calculs :
.divpourh2 {font-size: 1.1em;} h2 {font-size: 2em; font-size: 2.2rem;}
rendant de nouveau 'rem' superflu.

"Commentaires" le 4 mars 2014

1) Ce n'est pas une bonne idée de régler une font-size de base.
Eviter 62.5% car on ne sait pas de quoi in fine,
certains rares navigateurs n'adoptant pas 16 px par défaut 
- le 13 juin 2014 : la détection de '.css("font-size")'
par jQuery renvoie une valeur en pixels, 
qui est celle de ce réglage si l'élément s'affiche en '1em'.
Et surtout liberté de l'utilisateur d'adapter
ses possibilités de lecture via le paramétrage du navigateur.

2) Pour savoir de quoi sont 62,5%, il faudrait contrarier
d'éventuelles préférences utilisateur, avec
html {
 font-size: 16px;
}
NB : mais en ce cas autant imposer directement
html {
 font-size: 10px;
}
sans prendre la peine du 62.5

Faut-il contrôler le rendu à ce point ?

Sans doute vaut-il mieux :

- s'abstenir de définir 'font-size' pour html et pour body, 
et prendre la peine de calculer en em en prenant 
comme base probable 16px - avec, dans certaines zones au pixel près
(mentions légales ?), une zone intermédiaire à 10px,
pour avoir en-dessous de l'em décimalement précis

- dans des projets à trop forte contrainte graphique :
html {
 font-size: 10px;
}
"et basta"