Tuesday, September 18th, 2007
In his post Parroting Pareto, Jeremy Keith says that HTML5 needs to cover cases that “fall far outside the 80%-90% curve”, in particular accessibility. “By their very nature, accessibility concerns are not going to affect the majority of users. That doesn’t mean they can be dismissed.”
My understanding of applying the 80/20 rule to the design of HTML5 is that the “80” isn’t about 80% of users. It is about (proverbial) 80% of authoring cases. That is, it doesn’t make sense to support (for accessibility or otherwise) things that people would only publish very rarely if engineering support for the rarity would complicate the implementation of the language significantly.
See Hixie’s email to the HTML WG on the topic.
Posted in WHATWG | 4 Comments »
Thursday, August 23rd, 2007
This article is a French translation of the article Why the Alt Attribute May Be Omitted.
La spécification de l'attribut alt a été retravaillée récemment, afin d'améliorer sa définition, en incluant une explication en profondeur de comment fournir le texte alternatif le plus approprié avec de réelles exigences éditoriales.
La spécification décrit des situations où le texte alternatif doit être précisé, où un attribut alt vide doit être utilisé et où, de façon plus sujette à controverse, l'attribut alt peut parfaitement être omis. Cette omission peut sembler être sujette à controverse, parce que au premier regard, cela ressemble à une tentative pour justifier la mauvaise pratique, contraire aux principes de l'accessibilité, qui consiste à oublier l'attribut alt ... Et à jeter un pavé dans la mare. C'est une confusion malheureuse qui nécessite qu'on s'y arrête un instant pour balayer les doutes qu'elle pourrait susciter chez bien des gens. Bien que cela puisse paraître rétrograde, la situation est ainsi bien meilleure.
Il y a bien des cas où le texte alternatif est tout simplement indisponible et où il y a peu de choses que l'on puisse faire pour remédier à la situation. Par exemple, la plupart des utilisateurs de sites de partage de photos comme Flickr n'auraient certainement aucune idée de quoi écrire comme texte alternatif, même si Flickr leur en offrait la possibilité. Et même si, bien sûr, tout le monde s'accorde à dire que si ce serait formidable si, comme la spécification l'encourage, tous les utilisateurs le faisaient, la plupart ne le feront tout simplement pas.
Le problème que nous venons de soulever est le suivant : que devons-nous faire dans le cas où aucun texte alternatif n'a été spécifié et où il reste virtuellement impossible à définir ? De nombreux systèmes actuels tentent de satisfaire la recommandation actuelle en matière de texte alternatif en générant ce texte à partir des métadonnées des images.
Flickr, par exemple, répète le titre de l'image ; Photobucket semble combiner le nom du fichier image, le titre et le nom de l'utilisateur - et Wikipédia reproduit de façon redondante la légende de l'image. Le problème de ces approches est qu'aucune d'entre elles ne fournit une information additionnelle utile à propos de l'image et, dans certains cas, cela est pire que de ne fournir aucun texte alternatif.
Le bénéfice que l'on peut retirer de permettre l'omission du texte alternatif, plutôt que de nécessiter une valeur vide est que cela permet de créer une distinction claire entre une image qui n'a pas de texte alternatif (comme une icône où une représentation graphique du texte environnant) et une image qui fait partie intégrante du contenu, mais pour laquelle aucun texte alternatif n'est disponible. Il a été dit que Lynx et Opera faisaient déjà cette distinction. Pour des images qui n'ont pas d'attribut alt, Lynx montre le nom du fichier et Opera le texte "Image", mais aucun des deux ne montre quoi que ce soit pour les images dont l'attribut est laissé vide. Il reste à déterminer si cette disctinction est effectivement utile dans l'affichage du contenu du "monde réel" et il y a réellement un débat à mener si vous avez des preuves à avancer.
On a suggéré que retirer la présence inconditionnelle de l'attribut alt affecterait la capacité des validateurs à montrer leurs erreurs aux utilisateurs et retirerait un bon outil de promotion de l'accessibilité. Cependant, utiliser les erreurs de validation comme un outil d'évangélisation de l'accessibilité n'est certainement une bonne façon d'envisager cette problématique.
Tandis qu'il est en effet très utile pour les auteurs de savoir quand ils ont oublié par erreur un attribut alt en cherchant à les obliger à l'utiliser de façon inconditionnelle, utiliser un outil aussi éculé qu'un validateur est contre-productif, car il encourage l'utilisation de textes générés automatiquement de pauvre qualité. Paralèllement, rien n'empêchera les outils de validation et d'édition web de signaler ces erreurs aux auteurs si tel est leur bon plaisir.
Aucun des bénéfices de l'accessibilité n'est perdu en acceptant le fait qu'il est impossible de forcer tout le monde à fournir un texte alternatif et en rendant l'attribut alt optionnel pour pouvoir s'assurer de la conformité d'un document. Personne ne proclame que la conformité au HTML 5 est équivalente à la conformité avec les recommandations d'accessibilité. Il y a de nombreuses choses qui sont considérés conformes techniquement en HTML, mais qui demeurent "inaccessibles" si elles sont mal utilisées. Rendre l'attribut alt techniquement optionnel ne se dresse pas contre les recommandations d'accessibilité, pas plus qu'il n'a un quelconque impact sur l'évangélisation de l'accessibilité. Il s'agit simplement d'accepter la réalité de la situation à laquelle nous faisons face, dans l'espoir de réduire la prolifération des textes alternatifs de mauvaise qualité générés automatiquement.
Posted in Browsers, Elements, Processing Model, WHATWG | 2 Comments »
Tuesday, August 21st, 2007
Ian Hickson announced on the WHATWG and public-html mailing lists that he's written a tool that exposes his list of open issues:
In response to the concerns over the lack of transparency that have
recently been expressed both in these mailing lists and on blog posts, I
have written a tool that exposes the issues I have on my list:
http://www.whatwg.org/issues/
You can even vote for an issue to indicate that it should be made a
priority (to do that, you'll have to have sent an e-mail that ended up
on that list, as I use that as a way to prevent random spammers from
trying to use this web app).
There's also a page that shows the current 20 most-voted-for issues:
http://www.whatwg.org/issues/top
That page also contains some notes on what I'm likely to work on next,
though this information isn't necessarily accurate.
In addition to the above, you can also get a notification of every change
to the spec using one of the following methods:
You can follow this twitter feed (you can even subscribe to this with
your mobile phone so that you get text messages for every checkin):
http://twitter.com/WHATWG
You can subscribe to this mailing list:
http://lists.whatwg.org/listinfo.cgi/commit-watchers-whatwg.org
You can browse recent changes to the spec here:
http://html5.org/tools/web-apps-tracker
If anyone wants to volunteer to summarise changes and post announcements,
please just do it! Don't ask for permission, ask for forgiveness! I'm not
sure what the process is to post to the HTML working group blog, but you
can post to the WHATWG blog just by signing up and writing a blog post
(just tell Lachlan afterwards so he can actually post it, we have that
limited to certain users because spammers were abusing the blog). You can
also post announcements to the WHATWG twitter feed using the form on the
front page of whatwg.org.
Cheers,
Posted in WHATWG | Comments Off on Seeing the open issues
Monday, August 20th, 2007
This is a French translation of the article: Presentation: How HTML5 can be used today.
Hier, j'ai fait une présentation pour Creuna puis au Geek Meet sur la façon dont HTML 5 peut être utilisé aujourd'hui. La présentation était faite en Suédois, et c'est pourquoi les diapos sont disponibles en Suédois.
L'audience était essentiellement composée de personnes dont le métier est de créer des sites web.
La discussion qui a suivie était intéressante, mais elle n'a pas été enregistrée et je ne peux pas me souvenir de toutes les questions qui ont été posées, malheureusement. En voilà toutefois quelques unes qui me reviennent en mémoire :
- Quand est-ce que HTML 5 sera effectivement utilisé par les développeurs web ?
- Ca dépend de vous.
- Quand est-ce que HTML 5 sera terminé ? Quels sont les délais prévus ?
- Le tout est de savoir à quelle vitesse les différents navigateurs l'implémenteront. Le groupe de travail du W3C pour HTML 5 indique qu'une recommandation pour ce langage sera disponible pour 2010, mais je ne pense pas qu'il soit réaliste de penser qu'à cette date les navigateurs l'auront implémenté totalement et correctement. Un délai de 15 ans me semble plus réaliste, mais cela ne veut pas dire pour autant que vous avez besoin d'attendre 15 ans pour utiliser HTML 5.
- Quel est l'intérêt d'utiliser Web Forms 2.0 plutôt que d'utiliser les formulaires HTML 4 et du Javascript ?
- Moins de travail pour les développeurs et un meilleur rendu pour les utilisateurs. Par exemple, utiliser un <input type=email> signifie pour le développeur qu'il n'a pas à écrire du Javascript côté client pour valider qu'il s'agit d'une adresse email et pour l'utilisateur qu'il peut choisir un mail dans son carnet d'adresse personnel (quelque chose qu'il est impossible d'implémenter en Javascript).
- Sera-t-il possible de style les nouveaux contrôles de formulaire avec du CSS ?
- Il sera sans doute possible de le faire de la même façon qu'il est actuellement possible de le faire. L'icône dans le contrôle email est ajoutée par Opera quand le contrôle de formulaire est stylé d'une façon ou d'une autre (je style en général le fond en blanc pour la faire apparaître).
- Peut-on styler ou modifier les messages d'erreur du formulaire ?
- Je ne suis pas sûr que vous puissiez les styler, mais vous pouvez cependant en changer le texte avec Javascript ou réécrire le mécanisme qui signale l'erreur et créer le votre avec Javascript.
- Est-il vrai que HTML 5 permettra l'utilisation de <font> ?
- Non, les développeurs ne pourront pas utiliser <font>. Cependant, les éditeurs WYSIWYG seront autorisés à émettre des balises <font>. Ils devront s'identifier avec une balise <meta>. Cette problématique a reçu beaucoup de feedback et pourrait être modifiée.
- Avez-vous besoin d'être compatible en ce qui concerne l'utilisation de /> ou > ?
- Non
- Si vous ne spécifiez pas quelle est la version d'un document HTML, comment pourrez-vous redéfinir le comportement d'un élément, plus tard, dans HTML 6 ?
- Il n'y a pas besoin de préciser la version : les navigateurs traitent tous les documents HTML de la même façon, sans prêter attention à la version à laquelle ils déclarent appartenir. Un bon exemple de cela est la balise <plaintext>, qui a été dépréciée depuis la première version de HTML et qui est encore supportée dans tous les navigateurs, même si vous spécifiez une version HTML 4 par le DOCTYPE.
- Est-ce que HTML 5 déprécie quelque chose ?
- Rien n'est déprécié en fait, mais certaines choses sont totalement interdites. Par exemple, l'élément <u> n'est pas autorisé dans des documents HTML 5 conformes. Mais les navigateurs continueront cependant à le supporter.
- Est-ce que html5lib peut parser n'importe quelle soupe de tags ?
- Oui.
- Est-ce que cela signifie que l'on peut convertir n'importe quel vieux document HTML en XML en la passant à la moulinette de html5lib ?
- Oui.
- Est-ce qu'on peut utiliser le tag <svg> dans HTML 5 ?
- Non, vous ne pouvez pas utiliser les espaces de nom (namespaces) en HTML 5. Vous pouvez cependant inclure du SVG dans XHTML5 puisqu'il s'agit simplement de XML.
Posted in WHATWG | 1 Comment »
Tuesday, August 14th, 2007
Nowe elementy w HTML 5 - t?umaczenie artyku?u New elements in HTML 5 z 7.08.2007 zamieszczonego na stronach IBM development.
Posted in WHATWG | Comments Off on Nowe elementy w HTML 5 (Polish)