Archive for the ‘Browsers’ Category
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 »
Thursday, August 23rd, 2007
The specification
of the alt attribute was recently worked on to thoroughly
improve its definition, including an in depth explanation of how to provide
appropriate alternate text, with clear authoring requirements.
The requirements describe situations where alternate text must be provided,
where an empty alt attribute must be used and, most controversially,
where the alt attribute may be omitted entirely. This
is controversial because at first glance, it seems like an attempt to endorse
the bad and inaccessible practice of omitting the alt attribute,
and thus yet another slap in the face for accessibility. That is an unfortunate
misconception that needs to be carefully examined to settle any concerns people
have. Although it may seem backwards, the situation is actually much more
positive.
There are many observed cases where alternate text is simply unavailable and
there’s little that can be done about it. For example, most users of photo
sharing sites like Flickr wouldn’t have a
clue how or why to provide alternate text, even if Flickr provided the ability.
While everyone agrees that it would be wonderful if all users did – indeed,
the spec strongly encourages that – most users simply won’t.
The problem being addressed is what should be done in those cases where no alt text
has been provided and is virtually impossible to acquire. With the current
requirement for including the alt attribute in HTML4, it has been
observed that many systems will attempt to fulfil the requirement by generating
alternate text from the images metadata.
Flickr, for example, repeats the images title; Photobucket appears
to combine the image’s filename, title and the author’s username; and Wikipedia
redundantly repeats the image caption. The problem with these approaches is
that using such values does not provide any additional or useful information about
the image and, in some cases, this is worse than providing no alternate text
at all.
The benefit of requiring the alt attribute to be omitted, rather
than simply requiring the empty value, is that it makes a clear distinction
between an image that has no alternate text (such as an iconic or graphical
representation of the surrounding text) and an image that is a critical part
of the content, but for which not alt text is available. It has
been claimed that Lynx and Opera already use this distinction.
For images without alt attributes Lynx shows the filename and
Opera displays "Image", but neither show anything for images with empty alt attributes.
It is still somewhat questionable whether this distinction is actually useful
and whether or not browsers can realistically make such a distinction with
real world content, and that is certainly open to debate if you have further
evidence to provide.
It has been suggested that taking away the unconditional requirement for the alt attribute
will affect the ability of validators to notify authors of their mistakes and
take away a useful tool for promoting accessibility. However, using validation
errors as an accessibility evangelism tool is not necessarily the only, nor
the best, way to address the issue.
While it is indeed very useful for authors to know when they have mistakenly
omitted an alt attribute, attempting to unconditionally enforce
their use, using a tool as blunt as a validator, is counter productive since
it encourages the use of poor quality, automatically generated text. Besides,
nothing will prevent conformance checkers and authoring tools from notifying
authors, if they so desire.
No practical accessibility benefits are lost by conceding the fact that you
cannot force everyone to provide alternate text and making the alt attribute
optional for the purpose of document conformance. No-one is claiming that conformance
to HTML5 equates to conformance with accessibility requirements. There are
lots of things that are considered technically conforming in HTML, yet still
inaccessible if used poorly. Making alt technically optional doesn't stand
in the way of accessibility requirements, nor greatly impact upon accessibility
evangelism. It just acknowledges the reality of the situation in the hope of
reducing the prevalence of poor quality, automatically generated alt text.
Posted in Browsers, Elements, Processing Model | 46 Comments »
Tuesday, August 14th, 2007
One of the misconceptions about the (X)HTML 5 effort is that there will be no noticeable benefits compared to HTML 4 or XHTML 1.0. Here is one thing to prove this wrong. (X)HTML 5 will have the only practically usable implementation of ruby markup. While this maybe won't make too much of a difference in Europe and America, it sure is good news to a pair of billion people in Asia - and a few thousand theologians and historians.
Ian Hickson, the editor of the HTML 5 specification, said on the WHAT WG mailing list just recently: "I have in fact already begun looking at exactly what the parsing and semantic requirements for <ruby> will have to be. It should be added to the spec in the coming weeks." Currently the only browser that natively supports ruby is Internet Explorer, at least somewhat. This should be great news for Microsoft. For once they will actually have a lead compared to Gecko based browsers, Opera, Konqueror or Safari in supporting a part of the HTML 5 spec.
Keith Bowes, in a recent comment on Molly's blog, says:
Personally, I don’t see the point of HTML5. HTML 4 was a big improvement over HTML 3.2: better internationalization, better support for style sheets, more structure and less presentation, some of the more questionable things were removed or put in the dust bin of de facto obsolescence, etc. But I really don’t see where HTML5 is better enough.
A pair of billion Chinese or Japanese speaking people will beg to differ - and a few thousand theologians. Ruby is a big improvement for them. But wait, I may hear. Ruby is not new. It has been part of XHTML 1.1 for many years now. To which I retort: My point exactly! XHTML 1.1 is namely useless! Here is what its spec says: Content must be served with an XML MIME-type, and we all know that one specific browser with a huge market share does not support true XHTML!
If I want to use ruby markup I can (a) serve XHTML 1.1 as text/html, against all rules and have all IE users benefit, or (b) serve it as it should to users of Gecko based browsers, that can support ruby through an extension, or to all CSS savvy browsers using dedicated CSS-rules. But I can't do both!
Since (X)HTML 5 will have two serializations, this problem will cease to exist. I may use ruby markup and still send my content as text/html.
But there is one more lesson to be learned from this. I am a strong advocate of accessibility - after all I am a theologian first and web developer second - but I see that some of my friends have mistrusted HTML 5 because of accessibility features not yet documented in the spec. Ask questions! I did for ruby. If I had gotten a not so positive response I would have argued my case strongly. But please withhold negative judgments for a while. The process is not over yet. The war is not lost.
Finally, how does ruby benefit theologians? As I see things the best way to produce interlinear reproductions of ancient texts - the kind that we grapple with all the time - is to use ruby markup, where the relationship between the ancient word and the translated word is made explicit also within the markup.
Posted in Browsers, Elements | 5 Comments »
Wednesday, June 27th, 2007
This is a Polish translation of Feed Autodiscovery, translated by Sebastian Snopek.
Ostatnio dodali?my typy linków do HTML 5. W szczególno?ci zdefiniowali?my mechanizm do automatycznego wykrywania
kana?u syndykacyjnego. Automatyczne wykrywanie (Autodiscovery)
sta?o si? rozpowrzechnione i szeroko stosowane od momentu swoich narodzin w 2002 roku,
stosuj?c element link z powi?zaniem alternatywnym i atrybut type okre?laj?cym rodzaj kana?u.
<link rel="alternate" type="application/atom+xml"
href="/feed.atom" title="Atom Feed">
<link rel="alternate" type="application/rss+xml"
href="/feed.rss" title="RSS Feed">
Je?li chodzi o kompatybilno?? wsteczn? musimy zachowa? wsparcie, a szczególnie, zdefiniowa? t? metod?.
Jednak?e, istniej? dwa g?ówne problemy z zastosowaniem powi?za? alternatatywnych:
- Kana?y syndykacyjne nie s? koniecznie alternetywn? reprezentacj? strony.
- MIME type nie jest dobrym wyznacznikiem, ?e ?ródlo jest kana?em.
Np.: hAtom stosuje zwyczajny HTML z typem MIME
text/html, jednak dalej
mo?e by? stosowany jako format kana?u syndykacyjnego.
Aby poruszy? t? spraw?, wprowadzili?my nowe powi?zanie kana?u, które wskazuje
na to, ?e dokument jest kana?em syndykacyjntm. Pozwala to teraz na linkowanie do wielu kana?ów zawieraj?cych tre?ci, które nie s? koniecznie
alternatywnymi wersjami strony.
<link rel="feed" type="application/atom+xml"
href="/feed/comments" title="All comments">
<link rel="feed" type="application/atom+xml"
href="/feed/summaries" title="Article Summaries">
Oznacza to równie?, ?e nie trzeba precyzowa? atrybutu type , aby link by? rozpoznany jako kana? syndykacyjny, a przegl?darki mog? go nadal pokazywa? na li?cie subskrypcji.
<link rel="feed" href="/feed" title="Articles">
Inn? korzy?ci? jest to, ?e je?li kiedy? pojawi si? nowy format kana?u syndykacyjnego to nie trzeba b?dzie czeka? na aktualizacje przegl?darki nowym typem MIME, aby przgl?darka traktowa?a go jako kana?. Na przyk?ad: je?li czytelnicy twojego kana?u maj? wsparcie mikrofoormatu hAtom, mo?na przeprowadzi? subskripcje dokumentu HTML , który zosta? zalinkowany jako kana?.
<link rel="feed" type="text/html"
href="/feed.html" title="All comments">
Aby zachowa? kompatybilno?? wsteczn?, definicja alternate mówi, ?e
je?li u?ywa si? go w kombinacji z atrybutem type z warto?ci? application/rss+xml lub application/atom+xml to jest on równie? s?owem kluczowym dla kana?u.
S?owo kluczowe kana?u mo?e by? równie? u?ywane w kombinacji z alternate mówi?c, ?e jest to kana? dla danego dokumentu.
<link rel="feed alternate" type="application/atom+xml"
href="/feed.atom" title="Atom Feed">
Jednak?e, wa?nym jest aby nie myli? tego z tym jak dzia?aj? arkusze alternatywne. Zachowanie rel="alternatywnego arkusza stylów" jest przypadkiem wyj?tkowym wtedy, gdy u?ycie alternate nie oznacza alternatywnej reprezentacji samego dokumentu. Je?li u?ywa si? go z arkuszem stylów, to warto?? type nie jest równa warto?ci kana?u.
<link rel="alternate stylesheet" type="application/atom+xml"
href="/feed.atom" title="This is not a feed!">
Mozilla ju? raportowa?a bagi zwi?zane z implementacj? nowego powi?zania feedu a poprawki do rel="alternatywnych arkuszy" s? planowanie w nowym Firefox 3.0.
Posted in Browsers, Elements | Comments Off on Automatyczne wykrywanie feedów (Polish)
Sunday, December 3rd, 2006
We’ve recently added link
types to HTML 5. In particular we defined
the mechanism for syndication feed autodiscovery. Autodiscovery has
become widely deployed and implemented already since its inception in
2002, using the link element with the alternate relationship and a type attribute
indicating the format of the feed.
<link rel="alternate" type="application/atom+xml"
href="/feed.atom" title="Atom Feed">
<link rel="alternate" type="application/rss+xml"
href="/feed.rss" title="RSS Feed">
For backwards compatibility, we must retain support for, and explicitly define,
that method. However, there are two main issues with using the alternate
relationship:
- Syndication feeds are not necessarily alternate representations of the page.
- The MIME type is not always a good indication that a resource is a feed.
For example, hAtom uses regular HTML with the MIME type
text/html, yet may
still be used as a syndication feed format.
To address this issue, we have introduced a new feed relationship which indicates
that the referenced document is a syndication feed. This now allows you to
link to several different feeds containing different content which are not necessarily
alternate versions of the page.
<link rel="feed" type="application/atom+xml"
href="/feed/comments" title="All comments">
<link rel="feed" type="application/atom+xml"
href="/feed/summaries" title="Article Summaries">
It also means that you do not need to specify the type attribute to have the
link recognised as a syndication feed and browsers can still show it in the
subscription list.
<link rel="feed" href="/feed" title="Articles">
Another benefit of this is that if there is ever a new syndication feed format,
you don’t have to wait for browsers to be updated with the new MIME type to
recognise it as a feed. For instance, if your feed reader supports the hAtom
microformat, you could subscribe to an HTML document that has been linked to
as a feed.
<link rel="feed" type="text/html"
href="/feed.html" title="All comments">
In order to retain backwards compatibility, the definition
for alternate says
that when used in combination with a type attribute with the value of either
application/rss+xml or application/atom+xml.then it implies the feed keyword
as well.
The feed keyword can also be used in combination with alternate to say that
it is specifically the feed for the current document.
<link rel="feed alternate" type="application/atom+xml"
href="/feed.atom" title="Atom Feed">
However, it’s important not to confuse this with the way alternate stylesheets
works. The behaviour of rel="alternate stylesheet" is a special
case where the use of alternate doesn’t mean an alternate representation
of the document itself. In fact, if when used together with stylesheet, that
is the one case where the type value cannot imply the feed value.
<link rel="alternate stylesheet" type="application/atom+xml"
href="/feed.atom" title="This is not a feed!">
Mozilla already has bugs filed for implementing
the new feed relationship and fixing its bug
with with rel="alternate stylesheet" which are planned for inclusion
in Firefox 3.0.
Posted in Browsers, Elements | 16 Comments »