Re: [whatwg] alt and title attribute exception
On Tue, 31 Jul 2012 14:03:02 +0200, Steve Faulkner faulkner.st...@gmail.com wrote: title has differing semantics to alt. In situations where alt it not present on an img but title is, in webkit based browsers the title attribute content is displayed on mouse hover and is also displayed in place of the image when images are disabled or not available. This implementation appears to contradict the must requirement in the spec. User agents must not present the contents of the alt attribute in the same way as content of the title attribute. As there is no way visual distinction between title content being displayed and of alt content in this case. To be very clear, you agree with the spec, think that WebKit is wrong and would not offer any applause if Opera were to use the title attribute to replace images when images are disabled and there is no alt attribute? you wrote: but I'm confused -- is falling back to title a Good Thing that people want browsers to implement, or is it just a quirk that some legacy browser had? Given that there is a semantic distinction in the spec between what alt content is and what title content is and a swathe of normative requirements/advice based on this distinction it would appear unwise to promote the use of title as fallback without providing normative requirements on provision of a method to distinguish between the two. *Note:* in terms of the accessible name calculation for an img element, if the image does not have aria-label or an aria-labelledby or an alt attribute, but does have a title attribute, then the title attribute is used as the accessible name. From an accessibility API perspective, no distinction is indicated as to the source of the accessible name (apart from in the Mac AX API). The last point is another reason why making the title attribute on images (without alt) conforming is that the semantics, for all users, are ambiguous. Yes, the semantic difference is clear. What I wanted to add to this discussion is confirmation that the title attribute is inaccessibly to mobile browser users and likely to remain so. I don't know what conclusions to draw or what the spec should say, but to me it seems unwise to use the title attribute at all... -- Philip Jägenstedt Core Developer Opera Software
Re: [whatwg] alt and title attribute exception
On Tue, Jul 31, 2012 at 12:18 PM, Philip Jägenstedt phil...@opera.com wrote: When this was last discussed in the HTML WG (January 2012) I opened a bug (MOBILE-275) for Opera Mobile to expose the title attribute in our long-click menu, arguing that one could not enjoy XKCD without it. I meant to report back to the HTML WG but forgot, so here it is. Unfortunately, the bug was rejected... quoting the project management: Sure it is nice to have, but noone else has it so we will not put our effort into this Firefox for Android (at least on the Nightly channel) displays the content of the title attribute on XKCD comics (up to a length limit which can often be too limiting) upon tap and hold: http://hsivonen.iki.fi/screen/xkcd-firefox-for-android.png Not to suggest that XKCD's title usage is OK but just to correct the noone else bit. it seems unwise to recommend using the title attribute to convey important information. Indeed. In addition to image considerations, I think http://www.whatwg.org/specs/web-apps/current-work/#footnotes is bad advice. -- Henri Sivonen hsivo...@iki.fi http://hsivonen.iki.fi/
Re: [whatwg] alt and title attribute exception
On Wed, 01 Aug 2012 14:56:23 +0200, Henri Sivonen hsivo...@iki.fi wrote:
On Tue, Jul 31, 2012 at 12:18 PM, Philip Jägenstedt phil...@opera.com
wrote:
When this was last discussed in the HTML WG (January 2012) I opened a
bug
(MOBILE-275) for Opera Mobile to expose the title attribute in our
long-click menu, arguing that one could not enjoy XKCD without it. I
meant
to report back to the HTML WG but forgot, so here it is. Unfortunately,
the
bug was rejected... quoting the project management:
Sure it is nice to have, but noone else has it so we will not put our
effort into this
Firefox for Android (at least on the Nightly channel) displays the
content of the title attribute on XKCD comics (up to a length limit
which can often be too limiting) upon tap and hold:
http://hsivonen.iki.fi/screen/xkcd-firefox-for-android.png
Not to suggest that XKCD's title usage is OK but just to correct the
noone else bit.
Thanks for pointing this out, either we did poor research or this is a new
feature. In any case, I'll forward this information to our internal bug.
Opera's context menus are a bit smaller than that, so I don't think adding
a few paragraphs of text at the top of them would work.
it seems unwise to recommend using the title attribute to convey
important information.
Indeed. In addition to image considerations, I think
http://www.whatwg.org/specs/web-apps/current-work/#footnotes is bad
advice.
Yeah, that looks like a pretty bad idea, even for sighted users on desktop
browsers, unless you also add span[title] { border-bottom: 1px dotted
black; } or similar to your CSS to make it more discoverable. Removing
that advice seems like a good idea.
--
Philip Jägenstedt
Core Developer
Opera Software
Re: [whatwg] alt and title attribute exception
Philip Jägenstedt Wed Aug 1 05:05:15 PDT 2012: On Tue, 31 Jul 2012 14:03:02 +0200, Steve Faulkner wrote: title has differing semantics to alt. In situations where alt it not present on an img but title is, in webkit based browsers the title attribute content is displayed on mouse hover and is also displayed in place of the image when images are disabled or not available. This implementation appears to contradict the must requirement in the spec. User agents must not present the contents of the alt attribute in the same way as content of the title attribute. As there is no way visual distinction between title content being displayed and of alt content in this case. To be very clear, you agree with the spec, think that WebKit is wrong and would not offer any applause if Opera were to use the title attribute to replace images when images are disabled and there is no alt attribute? [I suppose 'the spec' means the W3 HTML5 spec?] Question: I would be rather simple for Opera, would it not, to add some CSS that makes the @title be used as @alt replacement when the @alt is lacking? -- leif halvard silli
Re: [whatwg] alt and title attribute exception
Hi Philip, you wrote: To be very clear, you agree with the spec, think that WebKit is wrong and would not offer any applause if Opera were to use the title attribute to replace images when images are disabled and there is no alt attribute? I don't have a strong view on the display of title content as fallback when alt is absent. It would be preferable to disambigaute the source of the text by (for example) prefixing the text with title:. What browsers provide as fallback in the absence of the appropriate content is a different beast than the question of what we should promote as a conforming markup pattern. I do think that if browsers provide a single feature (title) to provide tooltip text and image fallback text (which is what we are talking about), coupled with giving authors the greenlight via the current conformance free pass, it will lead to its use and misuse, which is why the must level requirement on browsers not to display alt in the same way as title was included in the first place AFAIK - To deter browsers from displaying alt both as fallback and tooltip.I do not see a difference between alt being displayed as both fallback and tooltip and title being displayed as both fallback and tooltip. If someone can explain to me why one is good but the other is not, I would be appreciative. you wrote: Yes, the semantic difference is clear. What I wanted to add to this discussion is confirmation that the title attribute is inaccessibly to mobile browser users and likely to remain so. I don't know what conclusions to draw or what the spec should say, but to me it seems unwise to use the title attribute at all... Well this is what I brought up in the other fora that this issue is/was debated. The (almost) complete lack of display of title in mobile browsers. Henri's example of firefox on android is interesting , but of only limited utility since the text is truncated, the same issue occurs (truncation) for both alt and title on in various browsers, in some browsers the alt/title is omitted completely if the text is longer than a certain value [1] regards SteveF [1] http://www.paciellogroup.com/blog/misc/HTML5/alt-tests/screenshots.html On 1 August 2012 13:05, Philip Jägenstedt phil...@opera.com wrote: On Tue, 31 Jul 2012 14:03:02 +0200, Steve Faulkner faulkner.st...@gmail.com wrote: title has differing semantics to alt. In situations where alt it not present on an img but title is, in webkit based browsers the title attribute content is displayed on mouse hover and is also displayed in place of the image when images are disabled or not available. This implementation appears to contradict the must requirement in the spec. User agents must not present the contents of the alt attribute in the same way as content of the title attribute. As there is no way visual distinction between title content being displayed and of alt content in this case. To be very clear, you agree with the spec, think that WebKit is wrong and would not offer any applause if Opera were to use the title attribute to replace images when images are disabled and there is no alt attribute? you wrote: but I'm confused -- is falling back to title a Good Thing that people want browsers to implement, or is it just a quirk that some legacy browser had? Given that there is a semantic distinction in the spec between what alt content is and what title content is and a swathe of normative requirements/advice based on this distinction it would appear unwise to promote the use of title as fallback without providing normative requirements on provision of a method to distinguish between the two. *Note:* in terms of the accessible name calculation for an img element, if the image does not have aria-label or an aria-labelledby or an alt attribute, but does have a title attribute, then the title attribute is used as the accessible name. From an accessibility API perspective, no distinction is indicated as to the source of the accessible name (apart from in the Mac AX API). The last point is another reason why making the title attribute on images (without alt) conforming is that the semantics, for all users, are ambiguous. Yes, the semantic difference is clear. What I wanted to add to this discussion is confirmation that the title attribute is inaccessibly to mobile browser users and likely to remain so. I don't know what conclusions to draw or what the spec should say, but to me it seems unwise to use the title attribute at all... -- Philip Jägenstedt Core Developer Opera Software
Re: [whatwg] alt and title attribute exception
Hi leif, you wrote: [I suppose 'the spec' means the W3 HTML5 spec?] no, i believe we are discussing what's in HTML living standard. regards SteveF Philip Jägenstedt Wed Aug 1 05:05:15 PDT 2012: On Tue, 31 Jul 2012 14:03:02 +0200, Steve Faulkner wrote: title has differing semantics to alt. In situations where alt it not present on an img but title is, in webkit based browsers the title attribute content is displayed on mouse hover and is also displayed in place of the image when images are disabled or not available. This implementation appears to contradict the must requirement in the spec. User agents must not present the contents of the alt attribute in the same way as content of the title attribute. As there is no way visual distinction between title content being displayed and of alt content in this case. To be very clear, you agree with the spec, think that WebKit is wrong and would not offer any applause if Opera were to use the title attribute to replace images when images are disabled and there is no alt attribute? [I suppose 'the spec' means the W3 HTML5 spec?] Question: I would be rather simple for Opera, would it not, to add some CSS that makes the @title be used as @alt replacement when the @alt is lacking? -- leif halvard silli
Re: [whatwg] alt and title attribute exception
Hi Henri, you wrote: Firefox for Android (at least on the Nightly channel) displays the content of the title attribute on XKCD comics (up to a length limit which can often be too limiting) upon tap and hold: http://hsivonen.iki.fi/screen/xkcd-firefox-for-android.png; that's useful data, too bad about the truncation issue, as I pointed out in my recent email to the list, that is an issue for both alt/title fallback on some desktop browsers. philip wrote: it seems unwise to recommend using the title attribute to convey important information. The title attribute has sever limitations in its utiltity, if one goal is to provide accessible content, I detailed some some cases where it should and should not be used [1] Indeed. In addition to image considerations, I think http://www.whatwg.org/specs/web-apps/current-work/#footnotes is bad advice. I agree and have detailed the reasons why [2] [1] using the HTML title attribute http://www.paciellogroup.com/blog/2010/11/using-the-html-title-attribute/ [2] http://www.w3.org/html/wg/wiki/ChangeProposals/notitle_annotations regards Stevef -- Message: 5 Date: Wed, 1 Aug 2012 15:56:23 +0300 From: Henri Sivonen hsivo...@iki.fi To: whatwg wha...@whatwg.org Subject: Re: [whatwg] alt and title attribute exception Message-ID: CAJQvAufAJp=PN=gAKD3oUCL4suwwWdMg6= cfbqewrvgipvs...@mail.gmail.com Content-Type: text/plain; charset=UTF-8 On Tue, Jul 31, 2012 at 12:18 PM, Philip J?genstedt phil...@opera.com wrote: When this was last discussed in the HTML WG (January 2012) I opened a bug (MOBILE-275) for Opera Mobile to expose the title attribute in our long-click menu, arguing that one could not enjoy XKCD without it. I meant to report back to the HTML WG but forgot, so here it is. Unfortunately, the bug was rejected... quoting the project management: Sure it is nice to have, but noone else has it so we will not put our effort into this Firefox for Android (at least on the Nightly channel) displays the content of the title attribute on XKCD comics (up to a length limit which can often be too limiting) upon tap and hold: http://hsivonen.iki.fi/screen/xkcd-firefox-for-android.png Not to suggest that XKCD's title usage is OK but just to correct the noone else bit. it seems unwise to recommend using the title attribute to convey important information. Indeed. In addition to image considerations, I think http://www.whatwg.org/specs/web-apps/current-work/#footnotes is bad advice. -- Henri Sivonen hsivo...@iki.fi http://hsivonen.iki.fi/
Re: [whatwg] alt and title attribute exception
On Fri, 27 Jul 2012 11:34:03 +0200, Steve Faulkner faulkner.st...@gmail.com wrote: Hi all, The spec currently allows img without alt if the title attribute is present This is problematic for a number of reasons: 1. One of the functions of alt as implemented is that the text is displayed when images are disabled or not available . I ran some tests a while back[1] and found that while webkit based browsers display title attribute content if images are disabled or not available, IE, Firefox and Opera do not. I did a quick recheck and focund the implementations have not changed in the 2.5 years since I ran those tests. 2. title attribute content is commonly displayed as a tooltip that appears when a user moves their mouse over an element (in this case an img) It is long running issue (14 years or so) that tooltips and thus title attribute content is not displayed for keyboard only users. Browsers vendors are fully aware of the issue, but as yet there have not yet been moves to fix the issue* When this was last discussed in the HTML WG (January 2012) I opened a bug (MOBILE-275) for Opera Mobile to expose the title attribute in our long-click menu, arguing that one could not enjoy XKCD without it. I meant to report back to the HTML WG but forgot, so here it is. Unfortunately, the bug was rejected... quoting the project management: Sure it is nice to have, but noone else has it so we will not put our effort into this Also, we had concerns about where this belongs, UI-wise. The context menu is a bit too prominent to display it in, in my opinion. I would like to have this, as xkcd isn't the only web comic I read that uses it, but I can't think of a way of doing it that doesn't add bloat. AFAICT there's also no way to read the alt attribute on Opera Mobile. I don't know what conclusions to draw, but if the situation is the same on other mobile browsers and they are also unwilling to change, it seems unwise to recommend using the title attribute to convey important information. Of course, it would be equally unwise to use any other new or existing attribute unless mobile browsers expose them in some way. -- Philip Jägenstedt Core Developer Opera Software
Re: [whatwg] alt and title attribute exception
On Tue, 31 Jul 2012 11:18:37 +0200, Philip Jägenstedt phil...@opera.com wrote: AFAICT there's also no way to read the alt attribute on Opera Mobile. You mean title, right? (alt can be read by turning of image loading - although the famous bug http://a11ybugs.org/bug-3.php (I know a few versions of it in Opera's BTS) doesn't help). I don't know what conclusions to draw, but if the situation is the same on other mobile browsers and they are also unwilling to change, it seems unwise to recommend using the title attribute to convey important information. To understate it like an english gentleman :) Of course, it would be equally unwise to use any other new or existing attribute unless mobile browsers expose them in some way. Right. If we agree that something really matters, we can always file bugs against browsers. Or write extensions, for when the Opera Mobile build with that capability goes from labs to release :) cheers -- Chaals - standards declaimer
Re: [whatwg] alt and title attribute exception
On Tue, 31 Jul 2012 11:48:52 +0200, Chaals McCathieNevile w...@chaals.com wrote: On Tue, 31 Jul 2012 11:18:37 +0200, Philip Jägenstedt phil...@opera.com wrote: AFAICT there's also no way to read the alt attribute on Opera Mobile. You mean title, right? (alt can be read by turning of image loading - although the famous bug http://a11ybugs.org/bug-3.php (I know a few versions of it in Opera's BTS) doesn't help). I really did mean the alt attribute, I didn't try turning images off, just long-clicking... oops. I suppose that if mobile browsers fix Bug 3 *and* fall back to the title attribute in the absence of an alt attribute then it would be OK to use title instead of alt, but I'm confused -- is falling back to title a Good Thing that people want browsers to implement, or is it just a quirk that some legacy browser had? -- Philip Jägenstedt Core Developer Opera Software
Re: [whatwg] alt and title attribute exception
Hi Philip, the spec currently says of the alt attribute [1]: the value of the alt attribute provides equivalent content for those who cannot process images or who have image loading disabled (i.e. it is the img element's fallback content). The alt attribute does not represent advisory information. User agents must not present the contents of the alt attribute in the same way as content of the title attribute. And this is how it is treated in modern graphical browsers, it is not displayed unless images are disabled or not available and it is used as the accessible name for the image in accessibility APIs whether the image is available or not. Unlike the title attribute which is available in some browsers when a user hovers their mouse over an image with a title attribute. the spec currently says of the title attribute [2]: The title attribute represents advisory information for the element, such as would be appropriate for a tooltip. On a link, this could be the title or a description of the target resource; on an image, it could be the image credit or a description of the image. title has differing semantics to alt. In situations where alt it not present on an img but title is, in webkit based browsers the title attribute content is displayed on mouse hover and is also displayed in place of the image when images are disabled or not available. This implementation appears to contradict the must requirement in the spec. User agents must not present the contents of the alt attribute in the same way as content of the title attribute. As there is no way visual distinction between title content being displayed and of alt content in this case. you wrote: but I'm confused -- is falling back to title a Good Thing that people want browsers to implement, or is it just a quirk that some legacy browser had? Given that there is a semantic distinction in the spec between what alt content is and what title content is and a swathe of normative requirements/advice based on this distinction it would appear unwise to promote the use of title as fallback without providing normative requirements on provision of a method to distinguish between the two. *Note:* in terms of the accessible name calculation for an img element, if the image does not have aria-label or an aria-labelledby or an alt attribute, but does have a title attribute, then the title attribute is used as the accessible name. From an accessibility API perspective, no distinction is indicated as to the source of the accessible name (apart from in the Mac AX API). The last point is another reason why making the title attribute on images (without alt) conforming is that the semantics, for all users, are ambiguous. [1] http://www.whatwg.org/specs/web-apps/current-work/multipage/embedded-content-1.html#attr-img-alt [2] http://www.whatwg.org/specs/web-apps/current-work/multipage/elements.html#the-title-attribute regards Stevef On 31 July 2012 12:12, Philip Jägenstedt phil...@opera.com wrote: On Tue, 31 Jul 2012 11:48:52 +0200, Chaals McCathieNevile w...@chaals.com wrote: On Tue, 31 Jul 2012 11:18:37 +0200, Philip Jägenstedt phil...@opera.com wrote: AFAICT there's also no way to read the alt attribute on Opera Mobile. You mean title, right? (alt can be read by turning of image loading - although the famous bug http://a11ybugs.org/bug-3.php (I know a few versions of it in Opera's BTS) doesn't help). I really did mean the alt attribute, I didn't try turning images off, just long-clicking... oops. I suppose that if mobile browsers fix Bug 3 *and* fall back to the title attribute in the absence of an alt attribute then it would be OK to use title instead of alt, but I'm confused -- is falling back to title a Good Thing that people want browsers to implement, or is it just a quirk that some legacy browser had? -- Philip Jägenstedt Core Developer Opera Software http://www.paciellogroup.com/resources/wat-ie-about.html
Re: [whatwg] alt and title attribute exception
Apologies. the last sentence should have read: The last point is another reason why making the title attribute on images (without alt) conforming, IS NOT good for users, is that the semantics, for all users, are ambiguous. regards Stevef On 31 July 2012 13:03, Steve Faulkner faulkner.st...@gmail.com wrote: Hi Philip, the spec currently says of the alt attribute [1]: the value of the alt attribute provides equivalent content for those who cannot process images or who have image loading disabled (i.e. it is the img element's fallback content). The alt attribute does not represent advisory information. User agents must not present the contents of the alt attribute in the same way as content of the title attribute. And this is how it is treated in modern graphical browsers, it is not displayed unless images are disabled or not available and it is used as the accessible name for the image in accessibility APIs whether the image is available or not. Unlike the title attribute which is available in some browsers when a user hovers their mouse over an image with a title attribute. the spec currently says of the title attribute [2]: The title attribute represents advisory information for the element, such as would be appropriate for a tooltip. On a link, this could be the title or a description of the target resource; on an image, it could be the image credit or a description of the image. title has differing semantics to alt. In situations where alt it not present on an img but title is, in webkit based browsers the title attribute content is displayed on mouse hover and is also displayed in place of the image when images are disabled or not available. This implementation appears to contradict the must requirement in the spec. User agents must not present the contents of the alt attribute in the same way as content of the title attribute. As there is no way visual distinction between title content being displayed and of alt content in this case. you wrote: but I'm confused -- is falling back to title a Good Thing that people want browsers to implement, or is it just a quirk that some legacy browser had? Given that there is a semantic distinction in the spec between what alt content is and what title content is and a swathe of normative requirements/advice based on this distinction it would appear unwise to promote the use of title as fallback without providing normative requirements on provision of a method to distinguish between the two. *Note:* in terms of the accessible name calculation for an img element, if the image does not have aria-label or an aria-labelledby or an alt attribute, but does have a title attribute, then the title attribute is used as the accessible name. From an accessibility API perspective, no distinction is indicated as to the source of the accessible name (apart from in the Mac AX API). The last point is another reason why making the title attribute on images (without alt) conforming is that the semantics, for all users, are ambiguous. [1] http://www.whatwg.org/specs/web-apps/current-work/multipage/embedded-content-1.html#attr-img-alt [2] http://www.whatwg.org/specs/web-apps/current-work/multipage/elements.html#the-title-attribute regards Stevef On 31 July 2012 12:12, Philip Jägenstedt phil...@opera.com wrote: On Tue, 31 Jul 2012 11:48:52 +0200, Chaals McCathieNevile w...@chaals.com wrote: On Tue, 31 Jul 2012 11:18:37 +0200, Philip Jägenstedt phil...@opera.com wrote: AFAICT there's also no way to read the alt attribute on Opera Mobile. You mean title, right? (alt can be read by turning of image loading - although the famous bug http://a11ybugs.org/bug-3.php (I know a few versions of it in Opera's BTS) doesn't help). I really did mean the alt attribute, I didn't try turning images off, just long-clicking... oops. I suppose that if mobile browsers fix Bug 3 *and* fall back to the title attribute in the absence of an alt attribute then it would be OK to use title instead of alt, but I'm confused -- is falling back to title a Good Thing that people want browsers to implement, or is it just a quirk that some legacy browser had? -- Philip Jägenstedt Core Developer Opera Software http://www.paciellogroup.com/resources/wat-ie-about.html -- with regards Steve Faulkner Technical Director - TPG www.paciellogroup.com | www.HTML5accessibility.com | www.twitter.com/stevefaulkner HTML5: Techniques for providing useful text alternatives - dev.w3.org/html5/alt-techniques/ Web Accessibility Toolbar - www.paciellogroup.com/resources/wat-ie-about.html
Re: [whatwg] alt and title attribute exception
On Tue, Jul 31, 2012 at 1:03 PM, Steve Faulkner faulkner.st...@gmail.com wrote: The alt attribute does not represent advisory information. User agents must not present the contents of the alt attribute in the same way as content of the title attribute. [snip] In situations where alt it not present on an img but title is, in webkit based browsers the title attribute content is displayed on mouse hover and is also displayed in place of the image when images are disabled or not available. This implementation appears to contradict the must requirement in the spec. Debatable. It's not showing @alt on hover, so their presentation is different. I think showing @alt on hover, as IE used to do, was the behavior this text was intending to discourage. That this behavior was wrong was after all a major tenet of: http://www.hixie.ch/advocacy/alttext This was premised on @alt being (potentially long) equivalent text rather than being a short name for the image though. Once both @alt and @title can be used to provide what could loosely be called titling information, the rationale for presenting the two differently begins to weaken. -- Benjamin Hawkes-Lewis
Re: [whatwg] alt and title attribute exception
Hi Ben I was not talking about being displayed as a tooltip . I was referring to the display as a replacement for an image when images are disabled. There is no indication that the text is advisory information rather than a text alternative. So in this case alt is being displayed in the same way as title. Regards SteveF Sent from my iPhone On 31 Jul 2012, at 15:36, Benjamin Hawkes-Lewis bhawkesle...@googlemail.com wrote: On Tue, Jul 31, 2012 at 1:03 PM, Steve Faulkner faulkner.st...@gmail.com wrote: The alt attribute does not represent advisory information. User agents must not present the contents of the alt attribute in the same way as content of the title attribute. [snip] In situations where alt it not present on an img but title is, in webkit based browsers the title attribute content is displayed on mouse hover and is also displayed in place of the image when images are disabled or not available. This implementation appears to contradict the must requirement in the spec. Debatable. It's not showing @alt on hover, so their presentation is different. I think showing @alt on hover, as IE used to do, was the behavior this text was intending to discourage. That this behavior was wrong was after all a major tenet of: http://www.hixie.ch/advocacy/alttext This was premised on @alt being (potentially long) equivalent text rather than being a short name for the image though. Once both @alt and @title can be used to provide what could loosely be called titling information, the rationale for presenting the two differently begins to weaken. -- Benjamin Hawkes-Lewis
Re: [whatwg] alt and title attribute exception
Steve Faulkner on Tue, 31 Jul 2012 13:03:02 +0100, wrote, in reply to Philip Jägenstedt: but I'm confused -- is falling back to title a Good Thing that people want browsers to implement, or is it just a quirk that some legacy browser had? Given that there is a semantic distinction in the spec between what alt content is and what title content is and a swathe of normative requirements/advice based on this distinction it would appear unwise to promote the use of title as fallback without providing normative requirements on provision of a method to distinguish between the two. So, it is bad that the Webkittens fall back to using @title? I must admit that I don't understand how you reason. Because, when @title is used as fallback, then we _want_ @title to be treated as @alt. So why do need a method to distinguish the two, then? *Note:* in terms of the accessible name calculation for an img element, if the image does not have aria-label or an aria-labelledby or an alt attribute, but does have a title attribute, then the title attribute is used as the accessible name. From an accessibility API perspective, no distinction is indicated as to the source of the accessible name (apart from in the Mac AX API). On the old mac I have at hand, right now, then AXImage (of Accessibility Inspector) renders the @title content, when the @alt is lacking. There is no info about the fact that the AXImage stems from @title. But perhaps that has changed so that AT users are informed when the accessible name stems from the @title? The last point is another reason why making the title attribute on images (without alt) conforming is that the semantics, for all users, are ambiguous. And another place in the same letter you say: User agents must not present the contents of the alt attribute in the same way as content of the title attribute. As there is no way visual distinction between title content being displayed and of alt content in this case. Comments: (1) It does not follow, from the fact that the spec forbids @alt from being rendered as a tooltip, that a tooltip cannot be rendered as an @alt. (2) If the spec did not forbid @alt from render as a tooltip, then authors would be confused to write @alt texts that were excellent as tooltips but delbad/del inssub optimal/ins as @alt content. (Thus, it is based on the respect for how the two features are distinct.) Conversely, if @title render as @alt, then authors would perhaps write tooltips that served OK as @alt. If that is bad, then why is it bad? (3) The fact that @title is used as last resort when calculating the accessible name is because an accessible name is so important that even a tooltip can be useful for that purpose, when need be. So why would it be a big no no that a lacking @alt causes the @title to be rendered as @alt content? I think the spec's motivation for the current exception might be similar to the generator exception: It is done to not triggers authors to e.g. create empty @alt or repeated, meaningless @alt text of the kind alt=image - just in order to validate. I disagree strongly with the generator exception. But I cannot say I strongly disagree with the @title exception. With the introduction of ARIA, it has become even less critical to remove this exception, since ARIA includes the @title as a last resort anyhow. I'm uncertain about how lack of keyboard access to @title can be used against this exception, when both Webkittens and ARIA give them access to it. -- Leif Halvard Silli
Re: [whatwg] alt and title attribute exception
On Tue, Jul 31, 2012 at 3:39 PM, Steve Faulkner faulkner.st...@gmail.com wrote: I was not talking about being displayed as a tooltip . I was referring to the display as a replacement for an image when images are disabled. There is no indication that the text is advisory information rather than a text alternative. So in this case alt is being displayed in the same way as title. My point is whether WebKit is conforming depends on whether you try to apply the conformance requirement to individual aspects of how the attribute is presented or to the entire presentation. Your claim that it's non-conforming depends on applying it to individual aspects. That's not misreading the requirement, but it's not the only viable reading. -- Benjamin Hawkes-Lewis
Re: [whatwg] alt and title attribute exception
Hi Leif, There is a distinction between what browsers should do to provide fallback and what should be promoted in the spec as a desired authoring pattern. browsers support many non conforming markup patterns. Because webkit browsers display title attribute content if alt attribute is not present, it is not a reason for making the markup pattern conforming. I believe the reasoning for the must requirement for browsers not to display alt in the same way as title, was to remove a reason for authors to use alt to provide advisory information, if so, similarly making the use of title without alt non conforming removes the legitimacy of the markup pattern that results in the same thing. Anyway this discussion is moving off the crux of the issue with allowing title when alt is not available. It promotes the use of the title attribute for the presentation of text content for all users at all times when due to long running browser implementation realities it is not available to some users when it should be. regards Stevef On 31 July 2012 19:57, Leif Halvard Silli xn--mlform-...@xn--mlform-iua.nowrote: Steve Faulkner on Tue, 31 Jul 2012 13:03:02 +0100, wrote, in reply to Philip Jägenstedt: but I'm confused -- is falling back to title a Good Thing that people want browsers to implement, or is it just a quirk that some legacy browser had? Given that there is a semantic distinction in the spec between what alt content is and what title content is and a swathe of normative requirements/advice based on this distinction it would appear unwise to promote the use of title as fallback without providing normative requirements on provision of a method to distinguish between the two. So, it is bad that the Webkittens fall back to using @title? I must admit that I don't understand how you reason. Because, when @title is used as fallback, then we _want_ @title to be treated as @alt. So why do need a method to distinguish the two, then? *Note:* in terms of the accessible name calculation for an img element, if the image does not have aria-label or an aria-labelledby or an alt attribute, but does have a title attribute, then the title attribute is used as the accessible name. From an accessibility API perspective, no distinction is indicated as to the source of the accessible name (apart from in the Mac AX API). On the old mac I have at hand, right now, then AXImage (of Accessibility Inspector) renders the @title content, when the @alt is lacking. There is no info about the fact that the AXImage stems from @title. But perhaps that has changed so that AT users are informed when the accessible name stems from the @title? The last point is another reason why making the title attribute on images (without alt) conforming is that the semantics, for all users, are ambiguous. And another place in the same letter you say: User agents must not present the contents of the alt attribute in the same way as content of the title attribute. As there is no way visual distinction between title content being displayed and of alt content in this case. Comments: (1) It does not follow, from the fact that the spec forbids @alt from being rendered as a tooltip, that a tooltip cannot be rendered as an @alt. (2) If the spec did not forbid @alt from render as a tooltip, then authors would be confused to write @alt texts that were excellent as tooltips but delbad/del inssub optimal/ins as @alt content. (Thus, it is based on the respect for how the two features are distinct.) Conversely, if @title render as @alt, then authors would perhaps write tooltips that served OK as @alt. If that is bad, then why is it bad? (3) The fact that @title is used as last resort when calculating the accessible name is because an accessible name is so important that even a tooltip can be useful for that purpose, when need be. So why would it be a big no no that a lacking @alt causes the @title to be rendered as @alt content? I think the spec's motivation for the current exception might be similar to the generator exception: It is done to not triggers authors to e.g. create empty @alt or repeated, meaningless @alt text of the kind alt=image - just in order to validate. I disagree strongly with the generator exception. But I cannot say I strongly disagree with the @title exception. With the introduction of ARIA, it has become even less critical to remove this exception, since ARIA includes the @title as a last resort anyhow. I'm uncertain about how lack of keyboard access to @title can be used against this exception, when both Webkittens and ARIA give them access to it. -- Leif Halvard Silli -- with regards Steve Faulkner Technical Director - TPG www.paciellogroup.com | www.HTML5accessibility.com | www.twitter.com/stevefaulkner HTML5: Techniques for providing useful text alternatives - dev.w3.org/html5/alt-techniques/ Web Accessibility Toolbar -
