- From: Robert J Burns <rob@robburns.com>
- Date: Wed, 27 Aug 2008 20:32:32 +0300
- To: "T.V Raman" <raman@google.com>
- Cc: ian@hixie.ch, public-html@w3.org
Hi T.V. Raman,
I agree 100% with the exposure of media metadata. I proposed something
similar previously[1][2].
However, on the issue of making alt optional to allow authors to keep
track of the missing data is not necessary. The alt attribute can
still be required for HTML5 document conformance while authors can
still omit the attribute to indicate the document is incomplete. Those
are perfectly consistent approaches. By making the alt attribute
optional we make it impossible for the machine conformance checker to
determine that the data is missing. Whereas with the alt attribute
required always, authors can omit the alt attribute and the
conformance checker will notify them of an incomplete document.
We can also provide authoring tool norms that require authoring tools
to omit the alt attribute (and therefore leave the document non-
conforming) whenever the user elects to provide no alt text (or
indicate the alt text is null). Therefore I think always required alt
(combined with authoring tool norms) is much more consistent with the
goals you're seeking than the sometimes optional alt attribute.
Take care,
Rob
[1]: <http://esw.w3.org/topic/HTML/UANormAndDOMForMediaPropeties>
[2]: <http://www.w3.org/Bugs/Public/show_bug.cgi?id=5755>
On Aug 27, 2008, at 6:42 PM, T.V Raman wrote:
>
> Ian,
>
> Here is my perspective on this issue after reviewing the various
> options we have. I've taken the liberty of adding in one
> suggestion of my own as part of this proposal --- namely, add an
> img.getEXIFData() DOM method that returns the EXIF metadata for
> an image as a JSON dictionary.
>
>
> alt Attribute On img:Information Encoding And Markup LanguagesThe
> alt Attribute On img:Information Encoding And Markup Languages
> 1 The alt Attribute On img:Information Encoding And Markup Languages
> Here is a brief write-up on the use of alt on the HTML img tag. This
> is being written based on my personal experience of the Web, as well
> as from watching the Web evolve since its inception. I have used
> most of the available screenreaders on the market, though for my own
> work, I use Emacspeak --- The Complete Audio Desktop. Note that the
> design presented here is based on technical metrics such as the
> ability to encode information effectively — and is in no way aimed
> at defining or determining accessibility policy or conformance
> criteria. In my experience, mixing these has detremental effects on
> both the language design as well as the policies used to ensure
> accessibility.
>
> 1.1 Executive Summary:
> • Make alt optional.
> • Define additional role values for use with graphical elements
> including images.
> • Add new DOM method img.getEXIFData to pick out metadata from
> images generated from digital cameras.
> Accessibility is a function of the willingness and ability of Web
> authors to provide the right level of content. Policy should focus
> on increasing willingness, whereas language design should focus on
> enhancing the ability to create accessible information. Conflating
> the two often leads to cases where it becomes impossible to detect
> if a piece of content is inaccessible because of lack of willingness
> or ability.
>
> 1.2 Background
> The img tag in HTML can carry a short alternative textual
> description as the value of the alt attribute:
>
> <img src="http://emacspeak.sf.net/emacspeak.jpg" alt="Emacspeak
> Logo">
> The alt attribute was introduced in the earliest versions of HTML to
> allow for pages that included images to be rendered on text
> terminals. Over the years, it has been leveraged as an accessibility
> feature for helping blind users deal with pages that have images.
> The attribute has evolved into the primary poster child for
> accessibility — and in the process, we may well have lost sight of
> its failings.
>
> 1.3 What Are We Encoding?
> HTML4 made the alt attribute required i.e., documents with missing
> alt on img tags were considered to be in error. The design sketched
> here is put forth with the goal of making things better — both with
> respect to encoding the maximal amount of information about an
> image, while ensuring that instances where such information is not
> available are easily detectable.
>
> With attribute alt required, a conforming img tag can be in one of
> the following states:
>
> • Carry an alt attribute that describes the image.
> • Carry an alt attribute that is meaningless or otherwise unrelated
> to the image (a common spam technique in the early days of the Web).
> • Carry an alt attribute that is the empty string "" --- this idiom
> has been used to indicate that an image is purely decorative.
> In the above, (1) and (2) are not readily distinguishable. Spam
> checkers can detect abuse of attribute alt. However, it is
> impossible to detect that the provided description does not match
> the image, or that an attribute value of "" for an image is
> inappropriate because that image is not purely decorative.
>
> Also, as demonstrated by the example of the Emacspeak Logo above,
> authors even when well-intentioned are split on what to place in the
> value of the alt attribute when it's the single place they have for
> attaching metadata (for purposes of this discussion, I'll ignore the
> rarely if ever used longdesc property. Thus, an author could
> correctly ask if the alt attribute for the above example ought to
> have been any one (or perhaps all) of:
>
> • A yelow Labrador saying "Emacspeak — the complete audio desktop!".
> • Raman's guide-dog, Hubbell Labrador saying "Emacspeak — The
> Complete Audio Desktop!".
> See discussion about the role attribute later in this document for a
> solution.
>
> Viewed from a purely information encoding point of view, making
> attribute alt not required gives us one additional bit --- cases
> where the image description is not provided can drop the alt
> attribute altogether — rather than cloaking such cases by providing
> an empty string as the alt value.
>
> 1.4 HTML5 Going Forward
> Making alt optional in the manner described might appear to be a
> backward step from an accessibility perspective given that that
> attribute was required in HTML4. However, if making the attribute
> optional helps us distinguish cases where the information is
> missing, this is a win.
>
> In addition to instances where an author chooses to ignore
> accessibility altogether, there are practical usage scenarios where
> such alt text is missing:
>
> • Photo sharing sites, e.g., my own photo gallery at Picasa Gallery
> For Raman. Incidentally I upload pictures here, and at the time of
> upload dont know what each picture has — I then have friends and
> family annotate the pictures with meaningful comments. Notice that
> the resulting descriptions are far richer than any alt text that I
> might have been able to provide.
> • Street maps.
> • Satellite imagery.
> • Street view images.
> Given that ARIA is now being implemented in browsers, and that as a
> consequence, attribute role defined by that specification is
> integrated into HTML, I believe we have an excellent opportunity to
> improve the situation with respect to photo-sharing sites and other
> automatically generated digital imagery. We can extend the legal
> values accepted by attribute role with a small number of well-known
> values, e.g.:
>
> • role = 'photo'
> • role ='logo'
> • role ='drawing'
> • role = 'satellite image'
> I believe the right set of such values should be specified within
> the WAI-PF group and rolled into the HTML specification based on
> implementation experience. This will enable adaptive technologies
> produce the right form of feedback going forward.
>
> 1.5 Enhancing The DOM Methods On img
> This might also be a good time to expose one additional DOM method
> on element img given that :
>
> • The majority of the photos uploaded to the Web are from digital
> cameras.
> • Digital cameras produce EXIF metadata automatically.
> It would be advantageous to add a img.getEXIFData() method that
> returns a JSON dictionary containing the EXIF data found at the
> value of attribute src. I believe such a DOM method would be
> extremely useful for mainstream applications, and is consequently
> likely to be implemented in the browsers. Such a method would be a
> major win for accessibility over the current status-quo of
> attempting to stuff all image metadata into a single attribute.
>
> The img.getEXIFData() combined with meaningful role values on img
> elements would make the accessibility situation with respect to
> images significantly better than what it is today.
>
> Author: T.V Raman <raman@google.com>
>
> Date: <2008-08-26 Tue>
>
> HTML generated by org-mode 6.06b in emacs 23
>
>
>
> Ian Hickson writes:
>>
>> How to mark up images has been a controversial subject in the
>> development
>> of HTML5. A number of people have put forward contradictory
>> proposals.
>> There has been much disagreement about what we can reasonably
>> require of
>> Web authors and users. There has also been disagreement about
>> exactly to
>> what extent we should allow people to write Web pages when making
>> them
>> perfectly accessible would be what they consider undue effort.
>>
>> It has also been one of the areas that has had the least amount of
>> research and data presented, relative to the amount of opinion put
>> forward. This has made making informed decisions quite difficult.
>>
>>
>> We are faced with a number of proposals, which I have attempted to
>> list
>> here in no particular order. I'm sure I missed some, for which I
>> apologise.
>>
>> A. Require that every <img> element have an alt="" attribute
>> specified,
>> and require that every alt="" attribute have a non-empty value.
>>
>> B. Require that every <img> element that the author believes conveys
>> information that could not be removed from the page without
>> changing the
>> page's message have an alt="" attribute with a non-empty value, and
>> require that the other <img> elements have an alt="" attribute with
>> an
>> empty value.
>>
>> Variants:
>>
>> B.1. Do not allow pages to be written that contain <img> elements for
>> which suitable alternative text isn't available.
>>
>> B.2. Allow pages that contain <img> elements for which suitable
>> alternative text is for some reason not available to still be
>> conforming,
>> by:
>>
>> B.2.i. ...allowing those <img> elements to have the alt="" attribute
>> omitted altogether.
>>
>> B.2.ii. ...having some special syntax for those <img>s' alt=""s:
>>
>> B.2.ii.a. A special keyword in alt="".
>>
>> B.2.ii.b. A set of special keywords for alt="" for various
>> situations in
>> which this may be possible.
>>
>> B.2.ii.c. A special syntax for alt="" that provides free-form minimal
>> alternative text to be given.
>>
>> B.2.iii. ...having some new attribute for those <img>s:
>>
>> B.2.iii.a. A free-form field for minimal alternative text, plus
>> requiring
>> that attribute to be present and alt="" to be absent.
>>
>> B.2.iii.b. A set of special keywords for various situations in
>> which this
>> may be possible.
>>
>> B.2.iii.c. A boolean attribute, plus:
>>
>> B.2.iii.c.I. ...requiring that attribute to be present and alt=""
>> to be
>> absent.
>>
>> B.2.iii.c.II. ...requiring that attribute to be present and alt=""
>> to be
>> present with some minimal alternative text.
>>
>> B.2.iii.c.III. ...requiring that attribute to be present and alt=""
>> to be
>> present with one of a set of special keywords for alt="" for various
>> situations in which this may be possible.
>>
>> B.2.iv. ...requiring the alt="" in these cases to be included with
>> some
>> value that isn't actually replacement text, but is instead some
>> minimal
>> alternative text, without giving the user agent a way to
>> distinguish this
>> image from an image that has alternative text that is adequate for
>> complete substitution.
>>
>> B.2.v. ...requiring that all such images be in a link that points
>> to the
>> image itself.
>>
>> B.2.vi. ...requiring that all such images be in a link that points
>> to the
>> image itself or in a <figure> element with a <legend>.
>>
>> B.3. Have multiple levels of conformance, and only allow pages that
>> contain <img> elements for which suitable alternative text isn't
>> available
>> to conform to a "lesser" level.
>>
>> C. Require that alternative text be provided for simple images, but
>> say
>> that for more complex images, the alternative text be replaed by
>> "greek
>> text" (a placeholder that indicates the image is complex but doesn't
>> actually convey the image's meaning).
>>
>> D. Allow every <img> element to have alternative text provided but
>> not
>> actually requiring it.
>>
>> E. Do not allow alternative text to be provided at all.
>>
>>
>> To pick between these we have to use what little research we have
>> so far.
>> This consists of the following. I hope I haven't missed anything;
>> if I
>> have, please let me know.
>>
>> * We have data showing that there are pages that have images that
>> have no
>> alternative text available where the generators of the HTML are not
>> able to obtain that data.
>> Evidence:
>> http://lists.w3.org/Archives/Public/public-html/2008Aug/0602.html
>>
>> * We have shown that requiring alt="" attributes does not lead to
>> image
>> sharing sites requesting alternative text from their users.
>> Evidence: HTML4 requires alt="" attributes, yet Flickr doesn't
>> require
>> users to enter alternative text.
>>
>> * We have data showing that such sites are major sites and are an
>> important part of the Web ecosystem.
>> Evidence:
>> http://www.alexa.com/site/ds/top_sites?ts_mode=global&lang=none
>>
>> * We have data showing that braces are not used often in alt=""
>> attributes.
>> Evidence:
>> http://philip.html5.org/data/alt-in-braces.txt
>> http://damowmow.com/temp/alt-in-braces.txt
>> http://krijnhoetmer.nl/irc-logs/whatwg/20080603#l-65
>> http://krijnhoetmer.nl/irc-logs/whatwg/20080803#l-8
>>
>> * We have data showing that two thirds of pages have at least one
>> <img>
>> element that is missing an alt="" attribute, and a tenth of pages
>> have
>> at least one <img> element but none of them have an alt=""
>> attribute:
>> http://krijnhoetmer.nl/irc-logs/whatwg/20080803#l-15
>>
>> I have also watched a number of usability studies with visually
>> impaired
>> users browsing the Web, from which I have noticed the following:
>>
>> * Users get so much repetition from their screen readers that they
>> tune
>> it out. It's not unusual for a page titled "Bee keeping", say, to
>> sound
>> like this from a screen reader: "Bee keeping. Bee keeping.
>> Graphic. Bee
>> keeping. The practie of keeping bees is as old as...". Users
>> don't even
>> comment on this, but it is quite clear that it isn't optimal and in
>> fact in certain cases it is even actively harmful, because it
>> drowns
>> out more important information, for example in one study I
>> examined,
>> the user was at one point looking for a link on a page and it
>> took him
>> two or three scans through the section to find the link because
>> instead
>> of saying the equivalent of "Bee keeping. Link.", it said something
>> akin to "Bee keeping. Graphic. Link. Bee Keeping. Bee Keeping."
>>
>> * Users don't seem to navigate by images much. Navigating by headers
>> seems to be the most common, followed by navigating to the top of
>> the
>> page, navigating by line, and navigating along forms and tables.
>> This
>> could naturally be biased by the small sample of tasks in the
>> studies I
>> saw, but in none of the studies did the users even mention ever
>> doing
>> it, so even if it is occasionally done it doesn't seem common.
>>
>>
>> People have argued many things, which I have listed below with some
>> commentary.
>>
>>
>> On Thu, 7 Aug 2008, John C. Vernaleo wrote:
>>>
>>> I don't know much about screen readers, but I do know something
>>> about
>>> LaTeX, and I just don't see how the textual representation of
>>> equations
>>> scales very well past very simple equations. Even in the example
>>> here
>>> that sentence is just barely unambiguous. A more complex equation
>>> would
>>> be much worse and a matrix basically impossible. And I'm not
>>> convinced
>>> a human could do it any better than a program could.
>>
>> The solution for mathematics in HTML5 is MathML, so I don't really
>> wat to
>> spend too much time considering the legacy practice of using images
>> with
>> LaTeX fallback alt="" text.
>>
>>
>> On Fri, 8 Aug 2008, Philip Taylor wrote:
>>>
>>> There are other instances of the same problem - e.g. if I write a
>>> Web
>>> 2.0 Logo Generator that converts a user's text into an image in a
>>> certain typographical style, I would decide to set the alt text to
>>> be
>>> what the user typed in, because that's the closest the tool can
>>> get to
>>> an equivalent of the image; but then if the user types in some funky
>>> name for their site like "{Cuilr}", it'll trigger the special
>>> alt-attribute-gives-kind-rather-than-textual-equivalent processing
>>> in
>>> HTML 5 UAs, which is inappropriate and harmful here, so I'd have to
>>> worry about preventing that situation.
>>
>> On Fri, 8 Aug 2008, Dave Singer wrote:
>>>
>>> [...] we have to trade off whether that processing step (if first-
>>> char
>>> of user-text is "{" then pre-pend something) is worth it to get the
>>> feature we want -- really forcing people to think about whether they
>>> truly lack alt text, and if so, getting them to indicate why.
>>>
>>> Personally, I think it worth it, because the gain for one segment
>>> of the
>>> population (those needing alt text) is much greater and more
>>> important
>>> than the small pain for another (tool writers). [...]
>>
>> On IRC, Philip Taylor wrote:
>>>
>>> I think the described "gain for one segment of the population (those
>>> needing alt text)" comes from having any mechanism that gives a
>>> textual description of an image when no equivalent is available (and
>>> that requires authors to always write something, and hence to think
>>> about alt and (with non-zero probability) write something that's
>>> better than nothing); and this particular "small pain for another
>>> (tool writers)" is specific to the curly-brace syntax and doesn't
>>> seem to be a problem in any other proposed mechanism, because the
>>> other mechanisms don't add any complexity to the otherwise-pleasant
>>> situations where you really do have equivalent text.
>>>
>>> I think the gain is worthwhile, so I wouldn't want to go back to alt
>>> being optional; but I think the pain is real, so I'd prefer some
>>> other solution that has the same gain without the pain, but that
>>> involves tradeoffs against the pains (of varying levels of
>>> theoreticality) of other solutions, which is not trivial (if it's
>>> even possible) :-(
>>
>> On Sun, 10 Aug 2008, Smylers wrote:
>>>
>>> However, Ian showed that very few images currently have alt text
>>> delimited by braces. So, even though the above scenarios obviously
>>> could exist, they apparently don't do so in large numbers.
>>>
>>> So it may be that the net effect of the 'braces' proposal would be
>>> to
>>> improve alt text on many more images than legitimately otherwise
>>> have
>>> braces embracing their alt text -- such that a mis-interpreting a
>>> few
>>> 'false positives' is, on balance, a price worth paying.
>>
>> On further reflection, the image category does not seem that useful
>> anyway in the case of reading a page linearly. Off-hand I can think
>> of
>> four cases where it might be used:
>>
>> * Photo-upload sites: The sites know less about what the image
>> actually
>> is (screen shot, photograph, diagram, etc) than the users
>> visiting the
>> page -- even if the users are blind or have images disabled, the
>> odds
>> are that the context in which they reached the page, or the page's
>> title or comments, will be more useful in determining the type of
>> image
>> than anything the site could offer.
>>
>> * Fractal navigation, satellite imagery navigation, and other
>> automated
>> views of large bodies of graphical data: The user already knows
>> that
>> the image is a fractal, a map, or whatever. Once again, explicitly
>> calling this out specifically in the context of the image will do
>> nothing to help the user.
>>
>> * Webcams: The text surrounding the webcam will most likely cue the
>> user
>> into the purpose of the image. In most cases, if the user is not
>> specifically looking for a webcam (e.g. by visiting the webcam's
>> dedicated page directly), the user would likely not care about the
>> webcam anyway.
>>
>> * Blogs or galleries where there are photos that a blind
>> photographer has
>> made available for his friends: The context will almost always
>> cue the
>> user into the fact that the unknown images are photographs, so
>> explicitly having image category information isn't likely to be
>> useful.
>>
>> Pages aren't always read linearly, though. In particular, it has been
>> pointed out that speech synthesis users can navigate pages image by
>> image.
>> For this, they need orientating. (More research on this topic
>> really would
>> be useful. I couldn't find any videos of usability studies that
>> showed how
>> blind users doing image navigation. When I tried to use a screen
>> reader
>> myself, I found myself typically reading the whole page and jumping
>> forward a paragraph, or to the next header, or to the next link,
>> but never
>> navigating using images. I don't know why users would do this.)
>>
>> Normally an image would have alternative text, but for images that
>> fall
>> into the cases above, all we have is a category and a title. The
>> title is
>> what would be really helpful for orientation, since one could,
>> e.g., have
>> multiple webcams on a page. Thus, for this kind of use case it
>> seems that
>> always providing an image title in the title="" attribute whenever
>> the
>> alt="" attribute is omitted would work. Sadly, in many cases site
>> authors
>> don't want to have tooltips show up, so we can't do that.
>>
>> We could argue that such images must always be in links (e.g.
>> pointing to
>> the image itself) or in <figure> elements with <legend>s (thus
>> giving a
>> caption, and thus a context, to the image) but it's easy to come up
>> with
>> scenarios where that would be not what an author would really want.
>> We
>> don't want to use a brief category in the alt="" attribute here
>> either, at
>> least not without some indicator to go with it, because then that
>> would
>> hurt the usability of these pages in text browsers (where the whole
>> idea
>> is to replace the images with their replacement text and just pretend
>> there is no image).
>>
>> Given the lackluster reasoning behind having _category_
>> information, I
>> don't think we can actually argue that including the information is a
>> requirement, regardless of the syntax. Incidentally, this equally
>> applies
>> to when alternative text _is_ available, so I don't really see what
>> problem is being solved by the idea of describing the image
>> category for
>> images with alternative text. (But, if categorising images is
>> something
>> that people believe would be useful anyway, I would encourage them to
>> define a set of classes for the <img> element that declare the
>> image type,
>> e.g. class=photo, class=diagram, and so forth. If people want a
>> wiki page
>> to document this they should feel welcome to use the WHATWG wiki.)
>>
>>
>> Basically every proposal listed above (A-E and all the variants) have
>> pretty serious problems. We can't require that every image have non-
>> empty
>> alt, because there are images that do nothing to help image-free
>> users
>> (A). We can't say that making a site like Flickr requires asking
>> all users
>> for alternative text, since users simply won't provide that data
>> (B, B.1).
>> We can't just omit alt="" with nothing else, since then users of
>> image
>> navigation will get lost (B.2.i). We can't use special syntax,
>> since it
>> hurts sites that care about accessibility more than anyone else,
>> which
>> just hurts the accessibility cause (B.2.ii.a, B.2.ii.b, B.2.ii.c). We
>> can't introduce a new attribute because this will legitimise
>> omitting alt
>> far too much, again hurting the accessibility cause, and any new
>> attribute
>> will likely be misused to the point of making the attribute
>> useless, due
>> to the copy-paste mentality of authors who don't understand the spec
>> (B.2.iii.a, B.2.iii.b, .2.iii.c.I, B.2.iii.c.II, B.2.iii.c.III). We
>> can't
>> just use alt="" with captions instead of replacement text, as that
>> would
>> both give a mixed message for authors, reducing the quality of
>> alternative
>> text in general, and would make it harder to understand pages with
>> a lot
>> of images even if they used alt="" correctly, if they sometimes had
>> to use
>> this technique (B.2.iv). We can't require that all such images be
>> links or
>> be in a <figure>, since both of these over-constrain the author and
>> will
>> likely just be requirements that are ignored (B.2.v, B.2.vi). We
>> don't
>> want to have multiple levels of conformance because authors seem
>> happy to
>> aim for the lower level (as seen with HTML4 Transitional), and
>> because
>> just doing this still doesn't address the problem (we have to pick
>> one of
>> the other solutions for the "lesser" conformance class), and
>> because this
>> isn't necessarily something that is fixable (we want full
>> conformance to
>> be something that authors can always aim for) (B.3). We don't want
>> to just
>> say authors can punt on alternative text altogether, as that
>> doesn't help
>> accessibility (C). We don't want to not require alternative text at
>> all,
>> since in most cases alternative text is quite easy to add and
>> massively
>> helps non-image users (D). We don't want to ban alternative text as
>> there
>> is simply no other alternative for handling images these days (E).
>>
>> So. We need another option.
>>
>> Are there cases where the image is lacking good alt text that
>> wouldn't be
>> covered by one of the following?:
>>
>> - title="" attribute on the <img> itself
>> - <legend> of the <figure> that contains the <img>
>> - heading of the section that contains the <img>
>>
>> F. We could say that for these "key content without alt text"
>> cases, we
>> have the alt="" attribute omitted, but there must be at least one
>> of the
>> above, and the first of the above that is present must include
>> sufficient
>> information to orient the user.
>>
>>
>> On Sat, 16 Aug 2008, Steven Faulkner wrote:
>>>
>>> It would be useful to have some real world use cases clarified in
>>> respect to the changes:
>>>
>>> 1. When a user uploads an image in flickr (http://www.flickr.com)
>>> they
>>> are given the opportunity to provide a 'description', if they
>>> choose to
>>> provide a description it is placed into the alt attribute of the
>>> image
>>> (plus ' by xxxx').
>>>
>>> Is this conforming in HTML5? if not what would be an appropriate alt
>>> attribute content if no 'real alternative text' is available?
>>>
>>> example from flickr with description (the image is of a man on a
>>> bike):
>>> <img src="DSCF4330.jpg" alt="hubris is a curse by emispos">
>>
>> It seems redundant to me, given that the title and the author have
>> already
>> been given by that point on the page. It would be reasonable text
>> for a
>> title="" attribute, maybe.
>>
>> I would recommend not having an alt="" at all in this case, though
>> I'm
>> sure you disagree with that suggestion on principle.
>>
>>
>>> 2. When a user uploads an image in flickr (http://www.flickr.com)
>>> If a
>>> user does not provide a description the filename of the image
>>> (minus the
>>> file extension, plus 'by xxxx') if is used as the alt attribute
>>> content.
>>>
>>> Is this conforming in HTML5? if not what would be an appropriate alt
>>> attribute content if no 'real alternative text' is available.
>>>
>>> example from flickr:
>>> <img src="DSCF4330.jpg" alt="DSCF4330 by emispos">
>>
>> I doubt the file name is ever useful, and it probably hurts
>> accessibility
>> because of it. But in general my answer would be as above. Put this
>> value
>> in the title="" attribute and don't have an alt="" attribute. UAs
>> and TAs
>> in particular should indicate that this is an image and give its
>> title=""
>> attribute's value as its title, and not replace the image with the
>> alt=""
>> text wholesale.
>>
>>
>>> 3. on lolcats (http://icanhascheezburger.com/) users can add text
>>> to an
>>> image, if the text the user added to the image were used as the
>>> content
>>> of the alt attribute would that be conforming in HTML5? If not what
>>> would be an appropriate alt attribute content if no 'real
>>> alternative
>>> text' is available?
>>
>> This is equivalent to the other cases, IMHO.
>>
>>
>> On Sat, 16 Aug 2008, James Graham wrote:
>>>
>>> Arguably one could say that a title is not a text equivalent but
>>> users
>>> would be best served if UAs use @title in a manner similar to @alt
>>> if no
>>> alt text is available (with freedom to do something like say "image
>>> entitled foo" rather than just "foo"). The argument against that
>>> is that
>>> the title is already available inline so requiring the UA to
>>> present it
>>> twice wouldn't help anyone.
>>
>> Agreed.
>>
>>
>> On Sun, 17 Aug 2008, Steven Faulkner wrote to James:
>>>
>>> As you are unsure about what the spec prescribes, as am I, it
>>> would be
>>> very useful to get a ruling from the editor on how he intends the
>>> spec
>>> to be interpreted in such 'real world' cases.
>>
>> James' interpretation of what I wrote is exactly what I intended.
>>
>>
>> On Mon, 18 Aug 2008, Maciej Stachowiak wrote:
>>> On Aug 18, 2008, at 6:37 AM, David Poehlman wrote:
>>>>
>>>> adding provisions for access to many many public facilities was not
>>>> easy to meet either, but it became law and everyone benefits except
>>>> those who didn't want the disabled in.
>>>
>>> That's right, *public* facilities. Note that it is not legally
>>> mandated
>>> that every private dwelling must be made accessible, or that every
>>> handmade poster placed on a public bulletin board must have
>>> braille or
>>> audio equivalents. That is because the focus of accessibility law,
>>> and
>>> of our moral intuitions about the topic, is on public accommodations
>>> provided by institutions, not private actions of individuals.
>>>
>>> Flickr is one of many public sites featuring user-generated
>>> content that
>>> is mostly shared with friends and family, but which is mostly
>>> visible to
>>> the general public. In terms of our moral sensibilities about
>>> accessibility, it is more like a public bulletin board where
>>> anyone can
>>> put up a poster, than like the professional signage in a store or
>>> school.
>>
>> To make a decision on this <img> issue I also have to make some
>> ethical
>> determinations. In particular there is a conflict between allowing
>> any
>> author to publish content, and requiring all authors to publish
>> content
>> that is usable by anyone. I believe a middle-of-the-road approach
>> is best
>> here, allowing most authors to write content but only if they can
>> provide
>> alternative text for their images, while not requiring the effort to
>> create such alternative text to be so great as to take a
>> disproportional
>> amount of time and thus not requiring all authors to publish
>> content that
>> is usable by anyone. This is similar to how HTML5 doesn't require all
>> content to be written to be understandable by 3 year olds or dogs.
>>
>>
>> On Mon, 18 Aug 2008, David Poehlman wrote:
>>>
>>> accessibility is right not privilige.
>>
>> Nope, sorry, accessibility is a privilege. Indeed, _not_ providing
>> accessible markup is a human right (freedom of opinion and
>> expression,
>> UDHR article 19). On Tue, 19 Aug 2008, Smylers wrote:
>>
>>
>> On Mon, 18 Aug 2008, John Foliot wrote:
>>>
>>> Eric has it almost right. However, as I read the current Draft,
>>> there is no
>>> specific requirement for these attributes to be present (in the
>>> absence of
>>> appropriate @alt values) to be conformant. While the draft offers
>>> us:
>>>
>>> <figure>
>>> <img src="1100670787_6a7c664aef.jpg" alt="{photo}">
>>> <legend>Bubbles traveled everywhere with us.</legend>
>>> </figure>
>>>
>>> It is unclear however whether:
>>>
>>> <figure>
>>> <img src="1100670787_6a7c664aef.jpg" alt="{photo}">
>>> <legend></legend>
>>> </figure>
>>>
>>> ...would be conformant, as well as:
>>>
>>> <figure>
>>> <img src="1100670787_6a7c664aef.jpg" alt="{photo}">
>>> </figure>
>>>
>>> I suspect that most accessibility advocates could accept the first
>>> instance
>>> (I have in principle), however the second and third instances are
>>> effectively useless and should not be deemed conformant. I do not
>>> see this
>>> specificity in the draft spec, my only real issue at this time.
>>
>> If we use the proposal above (F), then the second and third above
>> would
>> not be conforming.
>>
>>
>> On Fri, 22 Aug 2008, Al Gilman wrote:
>>>
>>> If the agent putting the markup together really doesn't have a
>>> clue (not
>>> the Flickr case) then I don't really have a problem with it being
>>> absent
>>> and non-conforming.
>>
>> By definition if it is non-conforming we are saying we have a
>> problem with
>> it. Sites aren't allowed to make non-conforming pages, that's what
>> conformance means.
>>
>>
>>> In Ian's favorite case (not successfully isolated by the rule in the
>>> draft) of a page with one photo on it (the only <img>? not likely)
>>> and
>>> all about that photo, I would consider a 'nonce' text alternate of
>>> @alt='the photo' would be pretty good. And under these
>>> circumstances a
>>> null alt of @alt="" wouldn't be too bad. Of course an @aria-
>>> labelledby
>>> pointing to the page title which holds "what might have been a
>>> figure
>>> legend but isn't" would be better.
>>
>> So would the proposed solution above (F), where there is an implicit
>> "labelledby" association, also be ok?
>>
>>
>> On Sat, 23 Aug 2008, Leif Halvard Silli wrote:
>>>>
>>>> * Introducing attributes for features that are supposed to be an
>>>> indicator of a problem (lack of alt text, in this case) isn't good
>>>> language design, as it brings it too much into prominence.
>>>
>>> I don't see "lack of alt text" as "an indicator of a problem". But
>>> if we
>>> introduced @role, /then/ @alt would be come an indicator.
>>>
>>> Today, whether you write alt="" or alt="spacer", there is nothing
>>> which
>>> indicates any problem. Both could be wrong. Both validate.
>>
>> What I meant was that there is a problem (an image lacking suitable
>> replacement text) and that we are looking for a way to tell the
>> user agent
>> that this problem exists. Further I was saying that we don't want
>> to make
>> it obvious that there is a way to indicate this problem, since that
>> might
>> encourage people to not include alternative text and just say "well
>> I said
>> that I didn't provide it so it's ok".
>>
>>
>>>> * An attribute would almost certainly be copied around
>>>> unintentionally by authors leading to it being at least as
>>>> unreliable
>>>> as the special syntax if not more.
>>>
>>> Should we anticipate1 that the role of a particular photo will
>>> change
>>> much and often depending on its context?
>>>
>>> For the photo website use case, I have proposed
>>> role="albumphoto". I do
>>> not think it would hurt much if that attribute would follow by if
>>> the
>>> image was copied to another context. Instead, it could help. There
>>> are a
>>> bunch of other possible @role-s which probably would work in many
>>> contexts: role=spacer, role=decor, role=potrait,
>>> role=mathexpression,
>>> role=text etc.
>>>
>>> Of course, an author should try to ensure he uses right role. But
>>> the
>>> danger of copy-pasting seems exaggerated in this case.
>>
>> Copy-and-paste is how massive amounts of the Web have come to be.
>> People
>> see something on one page, and misunderstand what it is for, and
>> put it on
>> their site even when they should not. e.g. we have many pages with
>> <br
>> xmlns=""> and <p/> and all kinds of crazy syntax.
>>
>>
>>>> * An attribute introduces a whole class of extra conformance errors
>>>> and complications, such as what to do when it is used with or
>>>> without
>>>> the alt="" attribute.
>>>
>>> I actually thought we were /looking/ for ways to do better
>>> validation -
>>> that's how I have understood Henri. Without @role, a validator
>>> cannot
>>> check much more than whether @alt is or isn't there.
>>
>> The point is that even with role, the validator still doesn't know
>> anything, since the role could be wrong. It just increases the
>> number of
>> possible things that could be wrong.
>>
>>
>> Anyway, categorising seems of limited use, as noted in detail above.
>>
>>
>> On Sat, 23 Aug 2008, Philip TAYLOR wrote:
>>> Ian Hickson wrote:
>>>
>>>> Speaking with my Google hat on for just this paragraph, I can
>>>> assure
>>>> you that with Picasa Web Albums, if we offered our users the
>>>> opportunity to specify alternative text, most wouldn't use it, if
>>>> we
>>>> required them to provide it, most would provide bogus text, and
>>>> if we
>>>> forced them to provide useful alternative text, they would all find
>>>> one of our competitors' sites and give up on Picasa altogether.
>>>> (Google hat off.)
>>>
>>> Speaking with my Picasaweb user's hat on, can you please
>>> substantiate
>>> this statement with /evidence/, not hypothesis and personal (or
>>> corporate) opinion? I can state with 100% certainty that I not only
>>> /want/ to add ALT text, I /need/ to be able to, in order that others
>>> (not necessarily sighted) can have equal access to my portfolios.
>>
>> We should probably offer alternative text as an option, I was just
>> saying
>> that we couldn't _require_ it from all users.
>>
>>
>>>> In practice, photo sharing sites will never have alternative text
>>>> available for the vast majorty of their images. Pretending
>>>> otherwise
>>>> is neither realistic nor productive.
>>>
>>> Awaiting substantiation.
>>
>> If you honestly think that there is any way that image upload sites
>> will
>> ever have suitable replacement text for the majority of their
>> images, then
>> I don't know what to tell you. It just won't happen.
>>
>>
>> On Sat, 23 Aug 2008, David Poehlman wrote:
>>>
>>> speaking as a blind user. I would not put up a photo with out an
>>> alt
>>> equiv.
>>
>> How could you possibly know what the image is enough to be able to
>> provide
>> replacement text? I'm honestly curious. I've spoken to other blind
>> users
>> about this and gotten quite different responses, like "my alt=''
>> text is
>> always bogus! how am i supposed to know what the images are?".
>>
>>
>> On Sat, 23 Aug 2008, David Poehlman wrote:
>>>
>>> anytime you require the empty string, it is ambiguous. If it can be
>>> seen visually, it must be reflected textually. The image is there
>>> for a
>>> reason and that needs to be addressed.
>>
>> This seems to deny the existence of purely decorative images, which
>> seems
>> like an unusual position. When a restaurant has a picture hanging
>> on the
>> wall, do you require the restaurant to describe the image to you,
>> or is
>> the image of no consequence to you?
>>
>>
>> On Sat, 23 Aug 2008, Leif Halvard Silli wrote:
>>>
>>> A Solomonic solution:
>>>
>>> Hide the very image if a valid @alt is lacking.
>>> Hide the @alt text if a valid src="" URI is lacking.
>>>
>>> Note: all UAs, including Screen Readers, must conform!! ;-)
>>
>> This would only result in us being ignored by implementors.
>>
>>
>> CONCLUSION:
>>
>> I've put proposal F into the spec.
>>
>> I've based this on as much objective data as possible, as described
>> above.
>> If people disagree with this, I would like to encouarge them to
>> please
>> provide actual data to back up their opinion. Repeating arguments
>> that
>> have already been put forth isn't going to change anything, since
>> those
>> arguments have all been considered already (I have read every single
>> e-mail on the subject sent so far, and spent hours painstakingly
>> considering every option I could). W3C HTML WG members who think
>> that the
>> current proposal is again unacceptable, but who do not have new
>> information or arguments to put forward (i.e. who already know that I
>> disagree with their reasoning) are encouraged to take this up with
>> the
>> HTMLWG chairs directly.
>>
>> If people do want to do actual research here, I would love to see
>> more
>> usability study videos of blind users using the Web without
>> guidance, to
>> see how they actually interact with images. I think that that is
>> the level
>> of research we need to really make more informed decisions.
>>
>> --
>> Ian Hickson U+1047E )
>> \._.,--....,'``. fL
>> http://ln.hixie.ch/ U+263A /, _.. \ _
>> \ ;`._ ,.
>> Things that are impossible just take longer. `._.-(,_..'--
>> (,_..'`-.;.'
Received on Wednesday, 27 August 2008 17:33:18 UTC