Re: [whatwg] Alt text authoring Re: Conformance for Mail clients
Considering internationalization: the alternative text should be translated to the language of the surrounding text, of course. I would recommend such a workaround only if some alternative text is required; see the OP. The point is that the browser tells the viewer that ho is missing some information that the designer considers important. Chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Kornel Lesinski Sent: Sunday, April 22, 2007 9:18 PM To: Kristof Zelechovski Cc: whatwg Subject: Re: [whatwg] Alt text authoring Re: Conformance for Mail clients On Sun, 22 Apr 2007 18:58:13 +0100, Kristof Zelechovski [EMAIL PROTECTED] wrote: For (2): alt=(Your browser does not display graphic images). What's the point? Users who rely on alt attribute know that already, and unless exactly that phrase is required by the specification (= bad for i18n), it won't be any use for bots either. I think presence of the title attribute (which might be empty) could be required if alt is omitted: img title= src=canyon.jpg or maybe: img alt=- src=canyon.jpg and role of img src=canyon.jpg should be left undefined, allowing UAs to use heuristics to guess it. -- regards, Kornel Lesiński
Re: [whatwg] Alt text authoring Re: Conformance for Mail clients
On Apr 23, 2007, at 03:00, Andrew Sidwell wrote: Maciej Stachowiak wrote: How about: img src=gallery2.jpg alt= -- image could be omitted without changing the meaning of the document (screen readers or text-only browsers could just skip it) img src=gallery2.jpg noalt -- image cannot be omitted without changing the meaning, but no text equivalent is available (screen readers or text-only browsers / mail clients should give some indication that an image is there) I actively like noalt. I fail to see why noalt would better than the absence of the alt attribute. Web apps like Flickr could generate noalt with good confidence, but I don't see how quasi-WYSIWYG tools could be none the smarter with generating noalt than they could be with omitting alt. Therefore, I think the spec should cater for the behavior of Lynx here. Using alt= has always seemed like a hack to me, implying that it did have alternative text when really it didn't. Indeed. It is the obvious effect of trying to factor unrealistic ideals into conformance requirements. The harm-minimizing fix is to concede that you cannot force people to provide alt if they don't want to and make alt optional for the purposes of document conformance. -- Henri Sivonen [EMAIL PROTECTED] http://hsivonen.iki.fi/
Re: [whatwg] Alt text authoring Re: Conformance for Mail clients
It seems you should replace all embedded content images with links to download them as stand-alone resources if you want to be strictly conformant with the images are an alternative of text theory. I am not particularly happy with this method because I would have to use a graphic processor to add a caption to such an image. While it can be done using a script, even if the caption depends on the content language, it is a highly nonstandard trick. And you cannot easily copy such a caption as text without using OCR, which is also possible but equally uncommon and cumbersome. The alternative of embedding images as objects is unrealistic given Microsoft's current stance on the subject. Chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Henri Sivonen Sent: Monday, April 23, 2007 11:44 AM To: Andrew Sidwell Cc: WHATWG List Subject: Re: [whatwg] Alt text authoring Re: Conformance for Mail clients Indeed. It is the obvious effect of trying to factor unrealistic ideals into conformance requirements. The harm-minimizing fix is to concede that you cannot force people to provide alt if they don't want to and make alt optional for the purposes of document conformance. -- Henri Sivonen [EMAIL PROTECTED] http://hsivonen.iki.fi/
Re: [whatwg] Alt text authoring Re: Conformance for Mail clients
On Sun, 22 Apr 2007 01:26:55 +0100, Jon Barnett [EMAIL PROTECTED] wrote: By entirely omitted alt, do you still only mean WYSIWYG editors? If not, I agree. The distinction would be as follows: (1) img src=obvious.jpg alt=obvious - This image represents text, particularly the word obvious. Lynx should replace it with the word obvious and do nothing else. (2) img src=gallery2.jpg The image is part of the content and doesn't represent text. Lynx should indicate that the image is missing and offer a way to download it I'm a bit worried about this one - authors too often forget (or don't care) to add alt attribute, and this case gives it a different meaning. I think that for (2) there should be either magic alt value or some way of specyfing that alt was intentionally omitted, and not forgotten (special classname? presence of title attribute?). -- regards, Kornel Lesiński
Re: [whatwg] Alt text authoring Re: Conformance for Mail clients
On 4/22/07, Kornel Lesinski [EMAIL PROTECTED] wrote: On Sun, 22 Apr 2007 01:26:55 +0100, Jon Barnett [EMAIL PROTECTED] wrote: By entirely omitted alt, do you still only mean WYSIWYG editors? If not, I agree. The distinction would be as follows: (1) img src=obvious.jpg alt=obvious - This image represents text, particularly the word obvious. Lynx should replace it with the word obvious and do nothing else. (2) img src=gallery2.jpg The image is part of the content and doesn't represent text. Lynx should indicate that the image is missing and offer a way to download it I'm a bit worried about this one - authors too often forget (or don't care) to add alt attribute, and this case gives it a different meaning. I think that for (2) there should be either magic alt value or some way of specyfing that alt was intentionally omitted, and not forgotten (special classname? presence of title attribute?). -- regards, Kornel Lesiński The rel attribute isn't specified for the img element, but this might be a good use for it - what relationship does this image have with the document. Thoughts on that, or something new? If the alt attribute is required, what should it be for (2)? Blank? A paragraph describing the vista of the Grand Canyon?
Re: [whatwg] Alt text authoring Re: Conformance for Mail clients
For (2): alt=(Your browser does not display graphic images). Chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jon Barnett Sent: Sunday, April 22, 2007 7:48 PM To: Kornel Lesinski Cc: whatwg Subject: Re: [whatwg] Alt text authoring Re: Conformance for Mail clients On 4/22/07, Kornel Lesinski [EMAIL PROTECTED] wrote: On Sun, 22 Apr 2007 01:26:55 +0100, Jon Barnett [EMAIL PROTECTED] wrote: By entirely omitted alt, do you still only mean WYSIWYG editors? If not, I agree. The distinction would be as follows: (1) img src=obvious.jpg alt=obvious - This image represents text, particularly the word obvious. Lynx should replace it with the word obvious and do nothing else. (2) img src=gallery2.jpg The image is part of the content and doesn't represent text. Lynx should indicate that the image is missing and offer a way to download it [snip] If the alt attribute is required, what should it be for (2)? Blank? A paragraph describing the vista of the Grand Canyon?
Re: [whatwg] Alt text authoring Re: Conformance for Mail clients
On Sun, 22 Apr 2007 18:58:13 +0100, Kristof Zelechovski [EMAIL PROTECTED] wrote: For (2): alt=(Your browser does not display graphic images). What's the point? Users who rely on alt attribute know that already, and unless exactly that phrase is required by the specification (= bad for i18n), it won't be any use for bots either. I think presence of the title attribute (which might be empty) could be required if alt is omitted: img title= src=canyon.jpg or maybe: img alt=- src=canyon.jpg and role of img src=canyon.jpg should be left undefined, allowing UAs to use heuristics to guess it. -- regards, Kornel Lesiński
Re: [whatwg] Alt text authoring Re: Conformance for Mail clients
At 07:45 +0200 UTC, on 2007-04-22, Charles McCathieNevile wrote: On Thu, 19 Apr 2007 15:43:14 +0200, Thomas Broyer [EMAIL PROTECTED] wrote: 2007/4/19, Matthew Paul Thomas: Thunderbird allows you to set 'alt' ... When you drag/drop an image into a message, the default is alt=. Setting a default of alt= is bad behaviour Indeed. As is careless reuse of previously entered data. See ATAG checkpoint 3.4: http://www.w3.org/TR/ATAG10/#check-no-default-alt [...] The application should simply leave out the alt attribute. This makes it trivially easy to build a repair application where one is required or desired, and has no practical drawback if the error is left in (given the state of HTML email standardisation...). Given that given that might be the best approach, yes. -- Sander Tekelenburg The Web Repair Initiative: http://webrepair.org/
Re: [whatwg] Alt text authoring Re: Conformance for Mail clients
On Apr 22, 2007, at 2:48 AM, Kornel Lesinski wrote: On Sun, 22 Apr 2007 01:26:55 +0100, Jon Barnett [EMAIL PROTECTED] wrote: By entirely omitted alt, do you still only mean WYSIWYG editors? If not, I agree. The distinction would be as follows: (1) img src=obvious.jpg alt=obvious - This image represents text, particularly the word obvious. Lynx should replace it with the word obvious and do nothing else. (2) img src=gallery2.jpg The image is part of the content and doesn't represent text. Lynx should indicate that the image is missing and offer a way to download it I'm a bit worried about this one - authors too often forget (or don't care) to add alt attribute, and this case gives it a different meaning. I think that for (2) there should be either magic alt value or some way of specyfing that alt was intentionally omitted, and not forgotten (special classname? presence of title attribute?). How about: img src=gallery2.jpg alt= -- image could be omitted without changing the meaning of the document (screen readers or text-only browsers could just skip it) img src=gallery2.jpg noalt -- image cannot be omitted without changing the meaning, but no text equivalent is available (screen readers or text-only browsers / mail clients should give some indication that an image is there) I'm not sure I like that better than just omitting alt entirely, but I thought I'd throw it out there. Regards, Maciej
Re: [whatwg] Alt text authoring Re: Conformance for Mail clients
Maciej Stachowiak wrote: How about: img src=gallery2.jpg alt= -- image could be omitted without changing the meaning of the document (screen readers or text-only browsers could just skip it) img src=gallery2.jpg noalt -- image cannot be omitted without changing the meaning, but no text equivalent is available (screen readers or text-only browsers / mail clients should give some indication that an image is there) I'm not sure I like that better than just omitting alt entirely, but I thought I'd throw it out there. When screen readers find img without alt, there typically attempt to fake alternative text using the src attribute. This can be done crudely (just reading the whole path) or selectively (just reading the filename, e.g. gallery2.jpg). Since authors will continue to fail to provide alternative text, screen readers are likely to continue employing such heuristics, defeating any attempt to attach a special new meaning to missing alt attributes. If images without alt are to be allowed, then noalt would be a reasonable hint. -- Benjamin Hawkes-Lewis
Re: [whatwg] Alt text authoring Re: Conformance for Mail clients
When screen readers find img without alt, there typically attempt to fake alternative text using the src attribute. This can be done crudely (just reading the whole path) or selectively (just reading the filename, e.g. gallery2.jpg). Since authors will continue to fail to provide alternative text, screen readers are likely to continue employing such heuristics, defeating any attempt to attach a special new meaning to missing alt attributes. If images without alt are to be allowed, then noalt would be a reasonable hint. -- Benjamin Hawkes-Lewis When UAs do what you describe, do they provide a way to download the image (text browsers) or indicate that what's missing in an image (screen readers)? What UAs? Is this different from how they currently behave when alt is present but blank? This page: !DOCTYPE html titleIMG test/title ol liImage represents a img src=PICT0023.JPG alt=tree liImage is content img src=PICT0023.JPG liImage is decorative img src=PICT0023.JPG alt='' /ol Is rendered by Lynx (on my machine) as: 1. Image represents a tree 2. Image represents is content [PICT0023.JPG] 3. Image represents is decorative Only in (2) does Lynx indicate that the image is missing. That's the behavior I would expect (even with noalt) Neither Firefox nor Konqueror distinguish between (2) and (3) with images disabled. noalt is a good idea and leaves no ambiguity. The current draft does say that a missing alt should be treated as if it's blank. Should that stay the same, or should special semantics be defined for a missing alt? Would any new semantics affect the DOM alt attribute? (I don't think it should.) I'd still like to know what other current UAs (screen readers) do with a missing alt. -- Jon Barnett
Re: [whatwg] Alt text authoring Re: Conformance for Mail clients
On Sun, 22 Apr 2007 19:58:13 +0200, Kristof Zelechovski [EMAIL PROTECTED] wrote: For (2): alt=(Your browser does not display graphic images). No. Where an alt would be required to makes sense of the image, but is not there, the attribute should simply be left out. Browsers have handled this error condition the best they can for years, and have various strategies for dealing with it ranging from adding image on demand (so users can download it, mail it to someone else, and ask what it is) to doing a complicated lookup on the web or in a local library for a version of the image that has been described. Putting any kind of default means breaking all backward compatibility with this work, and doesn't offer any improvement to anybody. Making up some standard phrase or adding some new attibute still breaks backward compatibility, still offers no substantive improvement, and involves agreeing on something that experts will argue is counterproductive in the first place. Where the author has deliberately decided not to have alt (e.g. because the image doesn't add anything important to a text version of the content), alt= is appropriate. Distinguishing this case from there authors have just not bothered to put anything in (or can't) is an important reason why it is a dreadful default to add. -Original Message- On 4/22/07, Kornel Lesinski [EMAIL PROTECTED] wrote: On Sun, 22 Apr 2007 01:26:55 +0100, Jon Barnett [EMAIL PROTECTED] By entirely omitted alt, do you still only mean WYSIWYG editors? If not, I agree. The distinction would be as follows: (2) img src=gallery2.jpg The image is part of the content and doesn't represent text. If the alt attribute is required, what should it be for (2)? Blank? A paragraph describing the vista of the Grand Canyon? Without context, this question is more or less impossible to answer in the general case. A useful alternative will give some information about how this image fits into the content of the page, without going into a detailed description. Ideally, that would be linked via longdesc for something like a sweeping vista of the grand canyon on the rainy winter day that I visited it in 2010, before it had been mostly filled in to provide the carpark that handles the millions of visitors now coming each month to see the exhibition 'what we lost - the empty canyon'. While browser handling of longdesc is almost universally woeful, the only exception I know of being iCab, there are plenty of extensions available, some built into screen readers, that dothe trivially simple job of making the description available. Options might include image 2 - vista of the canyon or image 2 (where the text already says what that is) or all kinds of other things. Writing alternative text is an art, not a science. There are parts of the art that are easily explained (although this discussion is a worrying sign that there is currently a disconnect between the people who understand something of the science and some of the people who are planning how the web should develop). cheers Chaals -- Charles McCathieNevile, Opera Software: Standards Group hablo español - je parle français - jeg lærer norsk [EMAIL PROTECTED] Try Opera 9.1 http://opera.com
Re: [whatwg] Alt text authoring Re: Conformance for Mail clients
On Mon, 23 Apr 2007 01:31:46 +0200, Jon Barnett [EMAIL PROTECTED] wrote:
When UAs do what you describe, do they provide a way to download the image
(text browsers) or indicate that what's missing in an image (screen
readers)? What UAs? Is this different from how they currently behave when
alt is present but blank?
This page:
!DOCTYPE html
titleIMG test/title
ol
liImage represents a img src=PICT0023.JPG alt=tree
liImage is content img src=PICT0023.JPG
liImage is decorative img src=PICT0023.JPG alt=''
/ol
Is rendered by Lynx (on my machine) as:
1. Image represents a tree
2. Image represents is content [PICT0023.JPG]
3. Image represents is decorative
Only in (2) does Lynx indicate that the image is missing. That's the
behavior I would expect (even with noalt)
Neither Firefox nor Konqueror distinguish between (2) and (3) with images
disabled.
Opera behaves like Lynx here under default conditions.
noalt is a good idea and leaves no ambiguity.
Except that it breaks all backward compatibility. Providing a way to download
the image is the job of a user agent (Opera's info panel says that there is 1
inline element - or 3 if I change the URIs to be unique), but I don't see how
it comes from markup. (In Opera you can get images with missing or null alt by
using the user mode 'alt text debugger' - you can add the user style
img { min-width:20px ; min-height 20px }
to that if you want to make easier targets for download).
The current draft does say that a missing alt should be treated as if it's
blank. Should that stay the same, or should special semantics be defined
for a missing alt?
User agents should treat this as an error. There is a procedure described in
the User Agent Accessibility Guidelines, which specifies a requirement to
handle this case as different from alt=:
[[[
2.7 Repair missing content (P2) Techniques for checkpoint 2.7
Allow configuration to generate repair text when the user agent recognizes that
the author has not provided conditional content required by the format
specification.
Sufficient techniques
The user agent may satisfy this checkpoint by basing the repair text on any of
the following available sources of information: URI reference (as defined in
[RFC2396], section 4), content type, or element type. Note, however, that
additional information that would enable more helpful repair might be available
but not near the missing conditional content. For instance, instead of
generating repair text on a simple URI reference, the user agent might look for
helpful information near a different instance of the URI reference in the same
document object, or might retrieve useful information (e.g., a title) from the
resource designated by the URI reference.
]]] - http://www.w3.org/TR/UAAG10/guidelines.html#tech-missing-alt
The original, plus some more explanation is provided at
http://www.w3.org/TR/UAAG10-TECHS/guidelines.html#tech-missing-alt
cheers
Chaals
--
Charles McCathieNevile, Opera Software: Standards Group
hablo español - je parle français - jeg lærer norsk
[EMAIL PROTECTED] Try Opera 9.1 http://opera.com
Re: [whatwg] Alt text authoring Re: Conformance for Mail clients
Options might include image 2 - vista of the canyon or image 2 (where the text already says what that is) or all kinds of other things. noalt is a good idea and leaves no ambiguity. Except that it breaks all backward compatibility. Can you please explain how? img src=grandcanyon.jpg alt=image 2 - vista of the canyon doesn't help the ambiguity. img src=grandcanyon.jpg title=image 2- vista of the canyon is more appropriate. The image does not represent that text, that text describes the image. The difference may seem subtle, but there is a difference. img src=rssicon alt=RSS is a case where the text serves no purpose than to represent the text RSS. Lynx can happily replace the image with the text as if the image doesn't exist. In the grand canyon example, Lynx should at indicate that the image does exist. This difference may be minor, but HTML doesn't explicitly tell authors how to mark up images that don't actually represent text and it's a distinction authors want to make. If noalt isn't acceptable, then let me suggest the rel attribute (with a couple suggested values). If the rel attribute was allowed on the IMG element, it could tell the relationship of the img to the document
Re: [whatwg] Alt text authoring Re: Conformance for Mail clients
On 4/19/07, Kornel Lesinski [EMAIL PROTECTED] wrote: On Thu, 19 Apr 2007 21:07:09 +0100, timeless [EMAIL PROTECTED] wrote: As such, encouraging people to include alt tags means the difference between me knowing that there's an image I care to look at and not. If e-mail client automatically inserted [image was here] in the text part of e-mail, you would know that there were images, even without user providing better alternative text. I support opinion that it doesn't make sense to _require_ e-mail clients to bug users about alternative text. On the web rationale for alt text is that you can never know who will read your page. In case of personal e-mail you do know. Pictures sent in personal e-mails almost never have function other than the picture itself - alt text for vacation photos, to be really an alternative, would have to be an essay. -- regards, Kornel Lesiński I've been following this and gathering thoughts. (Still) Images are used on the web (and in email) in 4 ways: 1. Images that represent text. pAlt text for this image is img alt=obvious src=obvious.jpg./p pIt's been a good day! img alt=:-) src=smile.jpg./p 2. Images that are content but don't represent text (though they may be accompanied by a caption - even if the caption could be the alt text, it would be redundant with the caption repeated in the markup) pThese are my vacation photos: ulliimg src=grandcanyon.jpgMy wife and I at the Grand Canyon.../ul 3. Images that are purely decorative, not content, and don't represent text pimg src=plant.jpg style=float: rightPotted plants are nice and love water... 4. Images that are purely background images - they're size isn't necessarily integral to layout, and the image may be repeated in the background - there's no ambiguity to this. div style=background: url(tiles)pLorem ipsum.../div It's obvious that the img tag should be used for (1) and obvious that CSS background images should be used for (4). (2) and (3) are the controversial examples. For (2), authors have a few choices: (a) Use the img tag and leave the alternate text blank. This is good because a graphical UA with no CSS would display the image, which is important to the content. This is bad because UAs can't tell the difference between (1) and (2). For example, Lynx would replace (1) with its alternate text but wouldn't have to provide a way to download the image. Lynx MUST provide a way for the user to download (2) because it's part of the content. Lynx needs to know the difference between (1) and (2) so it can let the user know which images are worth downloading and which images aren't (because downloading smile.jpg or obvious.jpg would be useless to the user). Requiring the alt attribute causes a problem here and simply leaving the attribute's value blank doesn't clear up enough ambiguity. (Some WYSIWYG editors will put the image's filename in the alt attribute by default causing even more ambiguity.) (b) Use a div or span styled with width and height and a background image. This isn't helpful to browsers that don't understand CSS and text browsers can't give the user a link to something to download. (c) Use the object tag with fallback content. This is probably the most useful option doesn't naturally cause any problems. The only real issue is that neither HTML4 nor HTML5 explicitly describe (1) and (2), and say to use img for (1) and object for (2) Some browsers have issues with the object tag and don't fall back appropriately. Also, object may not be semantically specific enough. No current WYSIWYG editors will use object by default for images or give users the option to choose with img alt=something is appropriate and when object is appropriate. Since this is the case, a better solution might be to specify that the alt attribute is optional. When the alt attribute is present, the image represents text. Non-graphical UAs* can replace the img with the text of the alt attribute silenty (or at least quietly). When the alt attribute is missing, the image is part of the content and non-graphical UAs should indicate that the image is missing and offer a method to download it. *Non-graphical UAs can include graphical UAs where the user has disabled graphics. For (3) authors have a few choices: (a) Use the img tag with a blank or missing alt attribute. This causes a conflict with (1) and (2). This image doesn't represent text so the UA shouldn't replace it with text. The image isn't part of the content, so Lynx shouldn't offer a link to download the image, because it's not useful to the user. (b) Use a div or span with CSS height, width, and background properties. This isn't always good for a couple reasons. The author may not know the dimensions of the image (e.g. the image's src is a PHP script that chooses randomly from a set of differently sized images). Also, this doesn't provide a way to scale the image. (c) Use a div or span with the CSS3
Re: [whatwg] Alt text authoring Re: Conformance for Mail clients
On 4/21/07, Maciej Stachowiak [EMAIL PROTECTED] wrote: How is an object with empty fallback content different from an img with an empty alt value? It seems like it is just as ambiguous, since if the fallback content were non-empty it should be substituted. I guess made an assumption that object semantically means embedded object that is part of the page content while img semantically means image that represents text, making the distinction between (1) and (2). Although, like I said, I think omitting the alt attribute is a better way to distinguish (2) from (1) I think a better option would be to distinguish alt=, and use that for images in the content that add no meaning as the draft says today, and no alt attribute at all for images that are meaningful, but where a text description is not available or appropriate. That's pretty much what I said at the end of the message, so I agree. We could limit img with no alt attribute to content generated by WYSIWYG editors, in the same way as font. Or something like that. That's where I disagree. I think it should be perfectly valid for authors to omit the alt attribute on images in a gallery for the same reason it's acceptable for YouTube not to have fallback content for its videos in embed tags. This does not just apply to WYSIWYG editor. Basically we can distinguish the two cases by alt= and entirely omitted alt. Regards, Maciej By entirely omitted alt, do you still only mean WYSIWYG editors? If not, I agree. The distinction would be as follows: (1) img src=obvious.jpg alt=obvious - This image represents text, particularly the word obvious. Lynx should replace it with the word obvious and do nothing else. (2) img src=gallery2.jpg The image is part of the content and doesn't represent text. Lynx should indicate that the image is missing and offer a way to download it (3) img src=decor.jpg alt= The image is purely decorational or represents text that would be redundant to display. Lynx should pretend it's not there. -- Jon Barnett
Re: [whatwg] Alt text authoring Re: Conformance for Mail clients
On Thu, 19 Apr 2007 15:43:14 +0200, Thomas Broyer [EMAIL PROTECTED] wrote: 2007/4/19, Matthew Paul Thomas: Thunderbird allows you to set 'alt' ... When you drag/drop an image into a message, the default is alt=. Setting a default of alt= is bad behaviour, since the program has no way of knowing what an appropriate alt might be (the behaviour described with user interaction is ideal), and makes an arbitrary decision that makes it more or less impossible to flag the problem and repair it later. The application should simply leave out the alt attribute. This makes it trivially easy to build a repair application where one is required or desired, and has no practical drawback if the error is left in (given the state of HTML email standardisation...). This should be lear from the W3C's authoring tool accessibility guidelines - http://www.w3.org/TR/ATAG which were desgined with a variety of tools in mind including CMS and email. cheers Chaals -- Charles McCathieNevile, Opera Software: Standards Group hablo español - je parle français - jeg lærer norsk [EMAIL PROTECTED] Try Opera 9.1 http://opera.com
Re: [whatwg] Alt text authoring Re: Conformance for Mail clients (and maybe other WYSIWYG editors)
On Thu, 19 Apr 2007 13:08:33 +0200, Maciej Stachowiak [EMAIL PROTECTED] wrote: On Apr 19, 2007, at 3:47 AM, Charles McCathieNevile wrote: Maciej Stachowiak wrote: I do think that for blogs or wikis where you are publishing to the web audience at large, the editing tools should make it possible and ideally even easy to add alt text. Probably not a mail client though. For the various reasons discussed in this thread, I cannot think of a real justification for making a mail client that breaks one of the basic accessibility features that people understand better than most others. And I can think of plenty of reasons for not doing so. I can only imagine it being useful as an advanced feature for experts. Normal people won't understand why a mail program would prompt them to type in some text about an image, that will then not be visible to them or their recipient. We may be closer to agreement than I think. To clarify, does this mean you agree that it should be possible, and ideally easy, to enter an alt text in a mail client, although you would suggest turning that option off by default? As a default, I am happy if clients only get that far. Since easy is such a wollly term, it isn't far at all - it boils down to having some kind of interface for doing this that users can turn on. I think a mail client where you cannot entre alt text for an image is a serious accessibility problem. In various cases where good record-keeping is required, the role of accessibility becomes more important. I guess this is why the US government foramlly requires software to associate text alternatives with images - whe you are sending mail around the department of defense, for example, you may have no idea who will be required to read it in three months or three years. cheers Chaals -- Charles McCathieNevile, Opera Software: Standards Group hablo español - je parle français - jeg lærer norsk [EMAIL PROTECTED] Try Opera 9.1 http://opera.com
Re: [whatwg] Alt text authoring Re: Conformance for Mail clients (and maybe other WYSIWYG editors)
On Thu, 19 Apr 2007 01:29:39 +0200, Benjamin Hawkes-Lewis [EMAIL PROTECTED] wrote: When I make HTML mail for (solicited) wide distribution, I make sure to include alt text. It's becomes especially important when clients are configured to automatically convert HTML mail to text (as indeed my own Thunderbird currently is). So it's not obvious to me that email composing programs don't need to make it easy to add alt text. ... Maciej Stachowiak wrote: ... I do think that for blogs or wikis where you are publishing to the web audience at large, the editing tools should make it possible and ideally even easy to add alt text. Probably not a mail client though. For the various reasons discussed in this thread, I cannot think of a real justification for making a mail client that breaks one of the basic accessibility features that people understand better than most others. And I can think of plenty of reasons for not doing so. cheers Chaals -- Charles McCathieNevile, Opera Software: Standards Group hablo español - je parle français - jeg lærer norsk [EMAIL PROTECTED] Try Opera 9.1 http://opera.com
Re: [whatwg] Alt text authoring Re: Conformance for Mail clients
2007/4/19, Matthew Paul Thomas: On Apr 19, 2007, at 10:47 PM, Charles McCathieNevile wrote: ... For the various reasons discussed in this thread, I cannot think of a real justification for making a mail client that breaks one of the basic accessibility features that people understand better than most others. And I can think of plenty of reasons for not doing so. ... As Benjamin said, it's worthwhile entering alt= text when sending to many recipients, and/or to unknown recipients; that is why alt= is important for public Web pages (where you don't know who is going to read a page) and for Intranets (where if a blind person joins the company tomorrow, they shouldn't be impeded by lack of alt= text on existing pages). But it seems likely that the vast majority of non-spam e-mail messages are sent to individuals who are known by the sender to be fully-sighted. In that case putting up an interface for entering alt= text, *just in case* the recipient gets struck blind before they get around to reading the message, seems a bit unreasonable. +1 Thunderbird allows you to set 'alt' (by default, the alternate text option is active, if you don't fill it, a message pops up when you click OK inciting you to fill the field in, or select the no alternate text option, in which case an empty alt= is generated). When you drag/drop an image into a message, the default is alt=. It would also be weird for a mail client to ask for alternate text for images in HTML messages (because HTML requires it), but not for images in multipart/mixed plain-text messages (because there's nowhere to put it). Yes there is: the Content-Description header. -- Thomas Broyer
Re: [whatwg] Alt text authoring Re: Conformance for Mail clients
On 4/19/07, Matthew Paul Thomas [EMAIL PROTECTED] wrote: But it seems likely that the vast majority of non-spam e-mail messages are sent to individuals who are known by the sender to be fully-sighted. In that case putting up an interface for entering alt= text, *just in case* the recipient gets struck blind before they get around to reading the message, seems a bit unreasonable. Just because I can see doesn't mean that my email client will show me pictures. In fact, most of the email clients I use don't at least half the time. As such, encouraging people to include alt tags means the difference between me knowing that there's an image I care to look at and not.
Re: [whatwg] Alt text authoring Re: Conformance for Mail clients
On Thu, 19 Apr 2007 21:07:09 +0100, timeless [EMAIL PROTECTED] wrote: As such, encouraging people to include alt tags means the difference between me knowing that there's an image I care to look at and not. If e-mail client automatically inserted [image was here] in the text part of e-mail, you would know that there were images, even without user providing better alternative text. I support opinion that it doesn't make sense to _require_ e-mail clients to bug users about alternative text. On the web rationale for alt text is that you can never know who will read your page. In case of personal e-mail you do know. Pictures sent in personal e-mails almost never have function other than the picture itself - alt text for vacation photos, to be really an alternative, would have to be an essay. -- regards, Kornel Lesiński
[whatwg] Alt text authoring Re: Conformance for Mail clients (and maybe other WYSIWYG editors)
On Mon, 16 Apr 2007 10:32:10 -0400, Maciej Stachowiak [EMAIL PROTECTED] wrote: On Apr 15, 2007, at 11:48 PM, Karl Dubost wrote: in a drag and drop scenario in your mail.app or other HTML authoring tool, you could imagine: [...] When the image is put in the window, a text is requested by the UI (a bit ala ajaxy flickr.) Then the markup could be generated. I don't think this is workable for HTML-generating mail clients or other tools for non-experts. You paste in an image and an area pops up to edit text that won't actually be visible in the mail message. This is likely to cause confusion and annoyance to users, and pretty unlikely to lead to good quality alt text. People would either just press enter, or type a description or caption (and then be annoyed when it disappeared) instead of substitute text. Consider in particular the case where you paste in a chunk of rich text content containing multiple images. There are a lot of ways of doing this in a UI. There are a lot of cases (Maciej you seem to have most of them mentioned already) where the appropriate alt is null. I think it remains the case that for end-user generated content, there will often be semantically meaningful images that are meaningful in themselves and cannot be considered alternate representations of some piece of text. Years of work on accessibility, and a particular focus on authoring tools, suggests that while this is certainly true, There are lots of good ways to enable authors to include an alternate. One of the big frustrations I find with the web today is using assorted tools like wikis and blogsto edit content, and not being able to put useful content for alt where appropriate, and mark it explicitly blank for other cases. Actually, given the relative distribution of disabilities and people, being able to put an image into content in the first place is probably more important than being able to put an alt to it - although the search engine case and various other things irrelevant to accessibility per se add to the value of alt. But it should still be possible. This is not really rocket science, but stuff that people have been working on for decades. When I had my first job working in IT accessibility in 1983 it was already a fairly straightforward problem. That it still gets discussed today is not a very flattering reflection on us as a development community. cheers Chaals -- Charles McCathieNevile, Opera Software: Standards Group hablo español - je parle français - jeg lærer norsk [EMAIL PROTECTED] Try Opera 9.1 http://opera.com
Re: [whatwg] Alt text authoring Re: Conformance for Mail clients (and maybe other WYSIWYG editors)
On Apr 18, 2007, at 11:56 AM, Charles McCathieNevile wrote: On Mon, 16 Apr 2007 10:32:10 -0400, Maciej Stachowiak [EMAIL PROTECTED] wrote: I think it remains the case that for end-user generated content, there will often be semantically meaningful images that are meaningful in themselves and cannot be considered alternate representations of some piece of text. Years of work on accessibility, and a particular focus on authoring tools, suggests that while this is certainly true, There are lots of good ways to enable authors to include an alternate. One of the big frustrations I find with the web today is using assorted tools like wikis and blogsto edit content, and not being able to put useful content for alt where appropriate, and mark it explicitly blank for other cases. I do think that for blogs or wikis where you are publishing to the web audience at large, the editing tools should make it possible and ideally even easy to add alt text. Probably not a mail client though. Regards, Maciej
Re: [whatwg] Alt text authoring Re: Conformance for Mail clients (and maybe other WYSIWYG editors)
When I make HTML mail for (solicited) wide distribution, I make sure to include alt text. It's becomes especially important when clients are configured to automatically convert HTML mail to text (as indeed my own Thunderbird currently is). So it's not obvious to me that email composing programs don't need to make it easy to add alt text. -- Benjamin Hawkes-Lewis Maciej Stachowiak wrote: On Apr 18, 2007, at 11:56 AM, Charles McCathieNevile wrote: On Mon, 16 Apr 2007 10:32:10 -0400, Maciej Stachowiak [EMAIL PROTECTED] wrote: I think it remains the case that for end-user generated content, there will often be semantically meaningful images that are meaningful in themselves and cannot be considered alternate representations of some piece of text. Years of work on accessibility, and a particular focus on authoring tools, suggests that while this is certainly true, There are lots of good ways to enable authors to include an alternate. One of the big frustrations I find with the web today is using assorted tools like wikis and blogsto edit content, and not being able to put useful content for alt where appropriate, and mark it explicitly blank for other cases. I do think that for blogs or wikis where you are publishing to the web audience at large, the editing tools should make it possible and ideally even easy to add alt text. Probably not a mail client though. Regards, Maciej
