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)
Thursday, May 24th, 2007
Yesterday I held a presentation first for Creuna and then at Geek Meet about how HTML5 can be used today. The presentation was held in Swedish, and thus the slides are also available in Swedish.
The audience was mostly people who work with creating Web sites.
The discussion afterwards was interesting, but it wasn't recorded and I can't recall all the questions, unfortunately. These are the ones I can recall for now however:
- When will HTML5 actually be used by web developers?
- That's up to you.
- When will HTML5 be finished? What is the time line?
- That's up to how fast browser vendors implement it. The W3C HTML WG's roadmap says that HTML5 will advance to Recommendation by 2010, but I don't think it is realistic to think that browser vendors will have implemented everything completely and correctly by then. Around 15 years is more realistic, however that doesn't mean that you will have to wait 15 years until you can use HTML5.
- What is the advantage of using Web Forms 2.0 instead of using HTML4 forms + JavaScript?
- Less work for authors, and a better user experience for users. For instance, using an <input type=email> means that the author doesn't have to write JS to validate that it is a correct email address on the client side, and the user can pick emails from her address book (something that is impossible to implement with JS).
- Can you style the new form controls with CSS?
- They can probably be styled to the same extent that existing form controls can be styled. The icon in the email control is added by Opera when the form control is styled in some way (I just set a white background color to make the icon appear.)
- Can you style or modify the form's error messages?
- I'm not sure if you can style them, however you can change the text with JS or override the error reporting mechanism and use your own custom mechanism with JS.
- Is it true that HTML5 allows <font>?
- No, authors are not allowed to use <font>. However, WYSIWYG editors are allowed to emit <font>. WYSIWYG editors have to identify themselves with a <meta> element. This has received a lot of feedback though and might be changed.
- Do you need to be consistent with the use of /> vs. >?
- No.
- If you don't specify what version of HTML a document is, how can you redefine the behavior of an element later in HTML6?
- You don't. Browsers treat all HTML documents the same way, regardless of what version they declare themselves of being. A good example of this is <plaintext>, which has been deprecated since HTML 1.0, and is still supported in all browsers even if you declare an HTML4 doctype.
- Does HTML5 deprecate anything?
- Nothing is actually deprecated, however some things are forbidden altogether. For example the <u> element is not allowed to be used in conforming HTML5 documents. Browsers will continue to support it, however.
- Can html5lib parse any tag soup?
- Yes.
- Does that mean that you can convert any old HTML document to XML by feeding it through html5lib?
- Yes.
- Can you use the <svg> tag in HTML5?
- No, you can't use namespaces in HTML5. You can however embed SVG in XHTML5, since it's simply XML.
Posted in WHATWG | 2 Comments »