E-mail List Archives
Thread: Title attributes on images and links
Number of posts in this thread: 24 (In chronological order)
From: E.J. Zufelt
Date: Tue, Aug 04 2009 10:50PM
Subject: Title attributes on images and links
No previous message | Next message →
Good evening,
Not to open a can of worms on the list, unless someone wants to open
it, but I am looking for authoritative articles on the proper use of
title attributes on links and images. My basic question is what is
the value of the title attribute if it is reasonably difficult for
some users to access? SEO, tooltip, other reasons?
Thanks,
Everett
Follow me on Twitter
http://twitter.com/ezufelt
View my LinkedIn Profile
http://www.linkedin.com/in/ezufelt
From: Benjamin Hawkes-Lewis
Date: Wed, Aug 05 2009 12:50AM
Subject: Re: Title attributes on images and links
← Previous message | Next message →
On 05/08/2009 05:47, E.J. Zufelt wrote:
> SEO, tooltip, other reasons?
From what I understand, it's little good for SEO since it's so often
abused for SEO keyword stuffing and can easily be discounted by search
engines.
Good use cases:
* Tooltips for image controls.
* Titles identifying frames and iframes
(http://www.w3.org/TR/WCAG-TECHS/H64.html)
There are cases where "title" is suggested as a suboptimal alternative
to other methods:
http://www.w3.org/TR/WCAG-TECHS/H33.html (vs. using text positioned
off-screen left)
http://www.w3.org/TR/WCAG-TECHS/H65.html (vs. using "label" elements and
positioning them off-screen left)
http://www.w3.org/TR/WCAG-TECHS/H89.html (vs. using text inside "label"
or "legend" and positioning it off-screen left)
See also:
http://tinyurl.com/25lf7a [RNIB]
--
Benjamin Hawkes-Lewis
From: Oliver Secluna
Date: Wed, Aug 05 2009 3:50AM
Subject: Re: Title attributes on images and links
← Previous message | Next message →
Personally I only use title in the following case: the link text (or alt
text of an image) is not sufficient to describe the page being linked
to.
This might be that the link text is "more info" so the title tag would
be "more info about [keyword]".
Another use would be to warn a user that a link opens a new window. In
this case my link text describes the linked page sufficiently, but the
title tag says "opens in new window".
Olly
>
From: Simius Puer
Date: Wed, Aug 05 2009 4:10AM
Subject: Re: Title attributes on images and links
← Previous message | Next message →
Sorry to take this a little off-topic but if you really must open new
windows (and I don't wish to re-enter that
argument<http://diveintoaccessibility.org/day_16_not_opening_new_windows.html>)
then "opens in a new window" would be considered far too valuable to be
hidden in title text as it can easily be missed by non-disabled users (it's
only appears at the last moment before a (sighted, mouse-using) user has
'clicked' on a link.
From: Oliver Secluna
Date: Wed, Aug 05 2009 4:20AM
Subject: Re: Title attributes on images and links
← Previous message | Next message →
I totally agree with this, and also don't like using 'more info' for
link text. However I work in a commercial environment where there is a
separation between us technical folk who do the coding and the clients
and designers who come up with the interface design. As a compromise
solution, where I have no control over the design or text that appears
on the page I use title text as a backup for accessibility and SEO.
Whether this is the best compromise or not, is open to discussion of
course.
>
From: E.J. Zufelt
Date: Wed, Aug 05 2009 4:30AM
Subject: Re: Title attributes on images and links
← Previous message | Next message →
On 5-Aug-09, at 6:16 AM, Oliver Secluna wrote:
> I totally agree with this, and also don't like using 'more info' for
> link text. However I work in a commercial environment where there is a
> separation between us technical folk who do the coding and the clients
> and designers who come up with the interface design. As a compromise
> solution, where I have no control over the design or text that appears
> on the page I use title text as a backup for accessibility and SEO.
>
E - Not sure if you're aware, but many screen-reader, and keyboard-
only, users do not have access to the title attribute, particularly
for links that have some link text. See the RNIB article that
Benjamin referenced at http://tinyurl.com/25lf7a [RNIB]
> Whether this is the best compromise or not, is open to discussion of
> course.
>
>>
From: Jared Smith
Date: Wed, Aug 05 2009 8:25AM
Subject: Re: Title attributes on images and links
← Previous message | Next message →
On Tue, Aug 4, 2009 at 10:47 PM, E.J. Zufelt< = EMAIL ADDRESS REMOVED = > wrote:
> I am looking for authoritative articles on the proper use of
> title attributes on links and images.
The title attribute, by definition in the spec, is for "advisory
information". By this definition, it probably should not be used to
convey vital or necessary information, particularly for accessibility.
I also interpret "advisory" to suggest that the title text should
probably be different from the element it is associated with (in other
words, title of "Products" on a "Products" link doesn't give anything
extra except an annoying tooltip). But it can be used on about any
element in HTML to convey pretty much any information you want.
By default, the title attribute is NOT read by screen readers, except
in a few cases - on form elements that do not have labels and on
frames. This is another reason why title should not be relied on for
accessibility for other elements. Screen reader users can enable the
reading of title attributes for images and links, though this is
relatively uncommon in my experience. One option in screen readers is
to read the longer of screen text/alt text or the title attribute
value.
Title text is not accessible at all to sighted keyboard users. It also
is not apparent to sighted mouse users unless and until they hover the
mouse over the element for a period of time.
Title is great for conveying additional *advisory* information that
might be helpful to sighted users who do not use a keyboard or for the
few screen reader users that might hear it. It's great for providing
additional cues, instructions, or details that are useful, but not
vital.
Because title generates a tooltip, it can sometimes cover or overlay
page elements essentially hiding them from view until the user moves
the mouse away from that element. For example, if the user loads a
page and the mouse is hovering over an element, the tooltip will
display. If the tooltip is covering another page element, the user
must manually move the mouse or scroll the page in order to hide the
tooltip.
My general recommendations:
- Use title if you want to when advisory information might be useful.
- Make sure the title text is brief and not the same as the visible
text or alt text.
- Recognize that many (most?) users will never know the title text is there.
- Do not use it for vital accessibility information, except on frames
and perhaps form elements that do not have labels (though I prefer
hidden labels because if title in this case is necessary for
accessibility, this sure seems to be more than "advisory" to me).
Hopefully that helps a bit.
Jared Smith
WebAIM
From: Nancy Johnson
Date: Wed, Aug 05 2009 8:30AM
Subject: Re: Title attributes on images and links
← Previous message | Next message →
Open in New Window: Managers love this, especially when the link
takes them away from their site or to open a pdf. It's an uphill
battle to educate folks enough to limit or not use target="blank".
Title Attribute: I came into a site loaded with title attributes on
every form field and link. The clients love it and use it as a tool
tip. I have begun to educate my program manager as to the
limitations of the title attribute as to basically a "mouse" only
event with limited screen reader access and if you use this, the
appropriate length of text, as the text was so long that even mousers
didn't have time to read before it disappeared.
The site actually has one form element the which was dynamically
constructed so the exact form field would repeat if the user clicked
on add another item and so the label for or id would never be unique.
Even though I raised this issue of 508 with my program manager, there
has been no push to correct the construction. I used the "title"
attribute instead. See this article from the W3C on the appropriate
to use the title attribute:
http://www.w3.org/TR/WCAG20-SCRIPT-TECHS/H65.html
Nancy
On Wed, Aug 5, 2009 at 6:29 AM, E.J. Zufelt< = EMAIL ADDRESS REMOVED = > wrote:
> On 5-Aug-09, at 6:16 AM, Oliver Secluna wrote:
>
>> I totally agree with this, and also don't like using 'more info' for
>> link text. However I work in a commercial environment where there is a
>> separation between us technical folk who do the coding and the clients
>> and designers who come up with the interface design. As a compromise
>> solution, where I have no control over the design or text that appears
>> on the page I use title text as a backup for accessibility and SEO.
>>
> E - Not sure if you're aware, but many screen-reader, and keyboard-
> only, users do not have access to the title attribute, particularly
> for links that have some link text. See the RNIB article that
> Benjamin referenced at http://tinyurl.com/25lf7a [RNIB]
>
>
>> Whether this is the best compromise or not, is open to discussion of
>> course.
>>
>>>
From: Dean Hamack
Date: Wed, Aug 05 2009 10:40AM
Subject: Re: Title attributes on images and links
← Previous message | Next message →
I'm a developer (not a manager), and I use targets in the two instances you
mentioned. Reasoning is this:
1. It's bad business to take people away from your site
2. I expect something that is a file (rather than a web page) to open in a
new window. I can't tell you how many times I've cursed at my screen because
I closed a pdf thinking I would find the site right behind it, but instead
closed the whole browser and had to go find the site again.
I do not however use "_blank". If you do that, it will open a new window for
every single link. Instead, I use a name like "el" (short for external
link). That way, every external link opens in the same window, rather than
generating a new window with each click.
On 8/5/09 7:26 AM, "Nancy Johnson" < = EMAIL ADDRESS REMOVED = > wrote:
> Open in New Window: Managers love this, especially when the link
> takes them away from their site or to open a pdf. It's an uphill
> battle to educate folks enough to limit or not use target="blank".
From: Karl Groves
Date: Wed, Aug 05 2009 11:15AM
Subject: Re: Title attributes on images and links
← Previous message | Next message →
> I'm a developer (not a manager), and I use targets in the two instances
> you
> mentioned. Reasoning is this:
>
> 1. It's bad business to take people away from your site
Actually, what I (and others) have found during usability testing is that
opening new windows is just as likely - if not more - to cause lost
visitors. Here's why:
What happens when a new window is opened via target is that the new window
overlays the old window in exactly the same size that the old window was
opened. Because statistics show that users' browser window size is
typically 87% or greater of the available screen space, the new window
which appears is essentially "full screen" and overlays the old window.
In usability tests what we found was that the new window opens and users
don't notice the new window appeared. They interact with this new window,
clicking around and such, and then when they're done (and want to go back
to *your* site), they begin clicking the "Back" button repeatedly,
eventually reaching where the initial location when the new window
appeared. In other words, they're not back at your site.
In frustration, they begin closing the browser. Now, what you might
expect is that they'd close this "new" window and realize along the way
that your original site is there underneath in the "original" window.
What actually happened, surprisingly, is that they somehow got to thinking
that the only way they could get back to your site was to start over
entirely from the beginning - shutting down all browser windows entirely
and starting anew.
The bottom line: Opening new windows via 'target' causes lost, frustrated
users. Frustrating users is really bad business.
I haven't worked out a solution, but one previous co-worker hypothesized
that we could avoid this problem by purposely making the new window
significantly smaller (something like 60% of full window size) via
JavaScript. The working idea here was that making the window
significantly smaller would grab the user's attention. It would require
them to resize the window manually and therefore make them fully aware
that the new window exists so that, when they decide they want to go back
to your site, they remember the new window appeared and that all they need
to do is close the new window.
We never got a chance to do a real A+B test with this approach, so I don't
know whether it solves the problem.
Personally, I'm averse to new windows anyway, but it seems an interesting
idea.
Karl
From: Dean Hamack
Date: Wed, Aug 05 2009 11:45AM
Subject: Re: Title attributes on images and links
← Previous message | Next message →
Hi Karl, responses to your points inline
On 8/5/09 9:52 AM, "Karl Groves" < = EMAIL ADDRESS REMOVED = > wrote:
> In frustration, they begin closing the browser. Now, what you might
> expect is that they'd close this "new" window and realize along the way
> that your original site is there underneath in the "original" window.
> What actually happened, surprisingly, is that they somehow got to thinking
> that the only way they could get back to your site was to start over
> entirely from the beginning - shutting down all browser windows entirely
> and starting anew.
>
> The bottom line: Opening new windows via 'target' causes lost, frustrated
> users. Frustrating users is really bad business.
Which is exactly what happens to me when I open a pdf in the same window.
Can't please all of the people all of the time I guess.
> I haven't worked out a solution, but one previous co-worker hypothesized
> that we could avoid this problem by purposely making the new window
> significantly smaller (something like 60% of full window size) via
> JavaScript.
Yep. In fact, that is the only way to open new windows and still have your
site validate as XHTML strict. In their infinite wisdom, the w3c decided to
deprecate the target attribute and force developers to use javascript to do
this very simple task.
I generally use a little icon to indicate that a link will be opened in a
new window (like the little arrows on wikipedia). I also use a title
attribute that says "open this link in a new window". But as was mentioned
earlier, this doesn't help the screenreader user much.
Unfortunately, this is one of those issues where there is no perfect
solution.
From: Caleb Tang
Date: Wed, Aug 05 2009 11:50AM
Subject: Re: Title attributes on images and links
← Previous message | Next message →
In terms of opening new window, it depends on user settings and browser. It
could open in one of the following:
1) New window - full screen
2) New window - last closed window size
3) New tab
I think it is ok to open in a new window as long as the user aware about it.
WebAIM website uses icon and title attribute to inform user if it opens in a
new window or link to another website. To support screen reader user, each
icon has a hidden text eg:
<a href="http://www.google.com" title="Link to External Site"
class="external"><img src="external.png" alt="" /> Google<span> - External
Link</span></a>.
Caleb Tang
Accessibility & Usability Consultant
On 05/08/2009 17:52, "Karl Groves" < = EMAIL ADDRESS REMOVED = > wrote:
>> I'm a developer (not a manager), and I use targets in the two instances
>> you
>> mentioned. Reasoning is this:
>>
>> 1. It's bad business to take people away from your site
>
> Actually, what I (and others) have found during usability testing is that
> opening new windows is just as likely - if not more - to cause lost
> visitors. Here's why:
> What happens when a new window is opened via target is that the new window
> overlays the old window in exactly the same size that the old window was
> opened. Because statistics show that users' browser window size is
> typically 87% or greater of the available screen space, the new window
> which appears is essentially "full screen" and overlays the old window.
>
> In usability tests what we found was that the new window opens and users
> don't notice the new window appeared. They interact with this new window,
> clicking around and such, and then when they're done (and want to go back
> to *your* site), they begin clicking the "Back" button repeatedly,
> eventually reaching where the initial location when the new window
> appeared. In other words, they're not back at your site.
>
> In frustration, they begin closing the browser. Now, what you might
> expect is that they'd close this "new" window and realize along the way
> that your original site is there underneath in the "original" window.
> What actually happened, surprisingly, is that they somehow got to thinking
> that the only way they could get back to your site was to start over
> entirely from the beginning - shutting down all browser windows entirely
> and starting anew.
>
> The bottom line: Opening new windows via 'target' causes lost, frustrated
> users. Frustrating users is really bad business.
>
> I haven't worked out a solution, but one previous co-worker hypothesized
> that we could avoid this problem by purposely making the new window
> significantly smaller (something like 60% of full window size) via
> JavaScript. The working idea here was that making the window
> significantly smaller would grab the user's attention. It would require
> them to resize the window manually and therefore make them fully aware
> that the new window exists so that, when they decide they want to go back
> to your site, they remember the new window appeared and that all they need
> to do is close the new window.
>
> We never got a chance to do a real A+B test with this approach, so I don't
> know whether it solves the problem.
>
> Personally, I'm averse to new windows anyway, but it seems an interesting
> idea.
>
> Karl
>
From: Karl Groves
Date: Wed, Aug 05 2009 12:00PM
Subject: Re: Title attributes on images and links
← Previous message | Next message →
> From: = EMAIL ADDRESS REMOVED = [mailto:webaim-forum-
> = EMAIL ADDRESS REMOVED = ] On Behalf Of Dean Hamack
> Sent: Wednesday, August 05, 2009 1:43 PM
> To: WebAIM Discussion List
> Subject: Re: [WebAIM] Title attributes on images and links
>
> Hi Karl, responses to your points inline
>
> On 8/5/09 9:52 AM, "Karl Groves" < = EMAIL ADDRESS REMOVED = > wrote:
>
> > In frustration, they begin closing the browser. Now, what you might
> > expect is that they'd close this "new" window and realize along the
> way
> > that your original site is there underneath in the "original" window.
> > What actually happened, surprisingly, is that they somehow got to
> thinking
> > that the only way they could get back to your site was to start over
> > entirely from the beginning - shutting down all browser windows
> entirely
> > and starting anew.
> >
> > The bottom line: Opening new windows via 'target' causes lost,
> frustrated
> > users. Frustrating users is really bad business.
>
> Which is exactly what happens to me when I open a pdf in the same
> window.
> Can't please all of the people all of the time I guess.
This isn't' an 'either-or' thing. I agree with you on the PDF thing.
In such a case, you could forcibly set the 'Content-Disposition' header to
be 'attachment', which will prompt the user with what to do with the file
(i.e. whether or not to open it in Adobe Reader. Again, I have no info
on what users' reactions would be to this approach, but may meet your
needs.
>
> > I haven't worked out a solution, but one previous co-worker
> hypothesized
> > that we could avoid this problem by purposely making the new window
> > significantly smaller (something like 60% of full window size) via
> > JavaScript.
>
> Yep. In fact, that is the only way to open new windows and still have
> your
> site validate as XHTML strict. In their infinite wisdom, the w3c
> decided to
> deprecate the target attribute and force developers to use javascript
> to do
> this very simple task.
That's OK. You'll have all new frustrations when HTML 5 comes out! ;-)
Besides, target wasn't removed from XHTML 1.1
http://www.w3.org/MarkUp/2004/xhtml-faq#target
As always, if there's an element or attribute you wish to use which
doesn't exist or is deprecated, then declare a different DTD and conform
to that.
Most people get XHTML wrong anyway: http://hixie.ch/advocacy/xhtml
>
> I generally use a little icon to indicate that a link will be opened in
> a
> new window (like the little arrows on wikipedia). I also use a title
> attribute that says "open this link in a new window". But as was
> mentioned
> earlier, this doesn't help the screenreader user much.
Well, if you're using an icon, then the alt attribute would work just
fine. Make sure the icon is within the link though:
<a href="http://www.example.com">Go <img src="foo.gif" alt="Opens in a new
window"></a>
Karl
From: Jukka K. Korpela
Date: Wed, Aug 05 2009 12:10PM
Subject: Re: Title attributes on images and links
← Previous message | Next message →
Karl Groves wrote:
>> Yep. In fact, that is the only way to open new windows and still have
>> your
>> site validate as XHTML strict. In their infinite wisdom, the w3c
>> decided to
>> deprecate the target attribute and force developers to use javascript
>> to do
>> this very simple task.
>
> That's OK.
The W3C did not force anything. They can deprecate whatever they want, and
people can still use the target attribute if they want to. Whether that's a
good idea is different thing. But W3C recommendations affect this only if
you wish to conform to them.
> You'll have all new frustrations when HTML 5 comes out!
> ;-)
Let's hope that HTML 5 will be as successful as XHTML 1.1! :-)
> Besides, target wasn't removed from XHTML 1.1
> http://www.w3.org/MarkUp/2004/xhtml-faq#target
That's really... er... should I say "politics" or "(bad) philosophy". Of
course target was removed from XHTML 1.1, along with many other features,
when "Transitional" features were all removed.
> As always, if there's an element or attribute you wish to use which
> doesn't exist or is deprecated, then declare a different DTD and
> conform to that.
Or just use it. The DTD stuff is only useful if you a) understand what DTDs
are and b) use validators. Both are useful things of course, but most
authors live without both of them.
> <a href="http://www.example.com">Go <img src="foo.gif" alt="Opens in
> a new window"></a>
For some reason, "Go Opens in a new window" doesn't strike me as an
exemplary link text, especially in the light of WAI recommendations and
usability perspective...
--
Yucca, http://www.cs.tut.fi/~jkorpela/
From: Dean Hamack
Date: Wed, Aug 05 2009 12:15PM
Subject: Re: Title attributes on images and links
← Previous message | Next message →
On 8/5/09 10:33 AM, "Karl Groves" < = EMAIL ADDRESS REMOVED = > wrote:
> This isn't' an 'either-or' thing. I agree with you on the PDF thing.
> In such a case, you could forcibly set the 'Content-Disposition' header to
> be 'attachment', which will prompt the user with what to do with the file
> (i.e. whether or not to open it in Adobe Reader. Again, I have no info
> on what users' reactions would be to this approach, but may meet your
> needs.
How do you do this in practice? I'd never heard of this until now.
> Well, if you're using an icon, then the alt attribute would work just
> fine. Make sure the icon is within the link though:
> <a href="http://www.example.com">Go <img src="foo.gif" alt="Opens in a new
> window"></a>
I use background images for all icons, so that won't work. However, as
someone else pointed out, I can simply use a hidden span in the link and
accomplish the same thing.
From: Simius Puer
Date: Wed, Aug 05 2009 12:20PM
Subject: Re: Title attributes on images and links
← Previous message | Next message →
Ah, damn...I really didn't mean to kick this old debate off again!
In fact, that is the only way to open new windows and still have your
> site validate as XHTML strict. In their infinite wisdom, the w3c decided to
> deprecate the target attribute and force developers to use javascript to do
> this very simple task.
>
- nope. The W3C depreciated it as it was in conflict with the goals of good
XHTML. Just as <bold> and <i> were depreciated because they were "style"
not "structure, the target= was depreciated because you should
*not*interfere with the users browser...if they want to open it in a
new link
they can!
as for 'forcing' developers to use JavaScript...finding away around a
restriction that is there for good reason is the developers fault and was
not the intention of the W3C.
Suggested reading for anyone still using any method of opening new
windows...
http://diveintoaccessibility.org/day_16_not_opening_new_windows.html
The argument about "not wanting a user to leave my site" holds no water
what-so-ever. It is as difficult to close a new window as it is to hit the
back button. If there is no back button though...because you have opened a
new window...then you have broken a simple function of the browser that is
pretty core to accessibility.
Somehow this argument always seems to focus back on (baseless) business
reasons for opening new windows and ignores simple rules of good design and
accessibility (which indirectly impact on your business negatively as a
result).
There are other ways to achieve what you want to do without forcing the
users browser to behave how *you *want it to!
Final part of my rant...go read #1 and #2 of
http://www.useit.com/alertbox/990530.html ...written years ago by Jakob
Neilsen and yet still argued over for all the wrong reasons.
From: Karl Groves
Date: Wed, Aug 05 2009 12:25PM
Subject: Re: Title attributes on images and links
← Previous message | Next message →
> From: = EMAIL ADDRESS REMOVED = [mailto:webaim-forum-
> = EMAIL ADDRESS REMOVED = ] On Behalf Of Dean Hamack
> Sent: Wednesday, August 05, 2009 2:12 PM
> To: WebAIM Discussion List
> Subject: Re: [WebAIM] Title attributes on images and links
>
> On 8/5/09 10:33 AM, "Karl Groves" < = EMAIL ADDRESS REMOVED = > wrote:
>
> > This isn't' an 'either-or' thing. I agree with you on the PDF thing.
> > In such a case, you could forcibly set the 'Content-Disposition'
> header to
> > be 'attachment', which will prompt the user with what to do with the
> file
> > (i.e. whether or not to open it in Adobe Reader. Again, I have no
> info
> > on what users' reactions would be to this approach, but may meet your
> > needs.
>
> How do you do this in practice? I'd never heard of this until now.
>
I usually do it with PHP, which you may or may not also use, so I don't
want to bore you with PHP babble if you're an ASP guy.
One quick & dirty way to do it would be with .htaccess
<Files *.pdf>
ForceType application/pdf
Header set Content-Disposition attachment
</Files>
This apparently can be made better with the following:
<FilesMatch ".(?i:pdf)$">
ForceType application/octet-stream
Header set Content-Disposition attachment
</FilesMatch>
I haven't used this approach, so YMMV.
Karl
From: Dean Hamack
Date: Wed, Aug 05 2009 12:50PM
Subject: Re: Title attributes on images and links
← Previous message | Next message →
On 8/5/09 11:19 AM, "Simius Puer" < = EMAIL ADDRESS REMOVED = > wrote:
> Just as <bold> and <i> were depreciated because they were "style"
> not "structure
Yes, but opening a link is behavior, not style or structure, so it's totally
irrelevant to the discussion.
> the target= was depreciated because you should
> *not*interfere with the users browser...if they want to open it in a
> new link
> they can!
Problem is that most people have no clue as to how to do this.
> as for 'forcing' developers to use JavaScript...finding away around a
> restriction that is there for good reason is the developers fault and was
> not the intention of the W3C.
That is your opinion, not fact. And I heartily disagree.
> The argument about "not wanting a user to leave my site" holds no water
> what-so-ever. It is as difficult to close a new window as it is to hit the
> back button.
That's not the problem. The problem is when someone clicks on a link to
another site, spends some time browsing around for a while, and then tries
to get back. They don't just have to click the back button once, they have
to click it 50 times (or more). It does hold water, because I've experienced
it personally.
From: Benjamin Hawkes-Lewis
Date: Wed, Aug 05 2009 1:05PM
Subject: Re: Title attributes on images and links
← Previous message | Next message →
On 05/08/2009 19:19, Simius Puer wrote:
> The W3C depreciated it
[snip]
> because you should *not*interfere with the users browser...if they
> want to open it in a new link they can!
This is a reasonable argument for making "target='_blank'"
non-conforming, although I don't entirely buy it.
But do you have a citation that shows this was the /actual/ reason why
HTML4 made "target='_blank'" non-conforming in Strict HTML, or are you
just putting forward a rationalization of the decision? I've never found
a record of the reasoning behind it.
--
Benjamin Hawkes-Lewis
From: Jared Smith
Date: Wed, Aug 05 2009 1:25PM
Subject: Re: Title attributes on images and links
← Previous message | Next message →
On Wed, Aug 5, 2009 at 12:50 PM, Dean Hamack wrote:
>> if they want to open it in a new link they can!
>
> Problem is that most people have no clue as to how to do this.
Are you sure? I think that most *DO* know how to open links in new
windows/tabs and that most do so regularly. Perhaps the reason why
some people don't know how or when to do this is because some
developers arbitrarily force new windows upon them, making it
difficult for users to understand when and how links should have this
behavior.
And to clarify the WebAIM code posted previously - we do not open
external links in new windows, but we do identify external links via
icon and accessible text so that users can decide themselves whether
to open them in a new window or leave our site altogether. Who am I to
make that decision for them?
Jared Smith
WebAIM
From: Dean Hamack
Date: Wed, Aug 05 2009 1:45PM
Subject: Re: Title attributes on images and links
← Previous message | Next message →
On 8/5/09 12:21 PM, "Jared Smith" < = EMAIL ADDRESS REMOVED = > wrote:
> Are you sure? I think that most *DO* know how to open links in new
> windows/tabs and that most do so regularly.
I'm certain that all of my non-techie friends have no idea how. I didn't
even know about the shift key method until someone mentioned it today. I use
Safari, and I just right click on a link and select "open link in new tab"
when I want to do so.
But once again, I expect pdfs to open in a new window, so I don't bother
doing it with those links.
From: Waltenberger, Lon (LNI)
Date: Wed, Aug 05 2009 4:35PM
Subject: Re: Title attributes on images and links
← Previous message | Next message →
How PDFs open is a user-controlled function of Adobe Reader, the most
widely used PDF reader.
Browsers also have user-controlled defaults and options.
Jared's questioning his/our right to make decisions for users clearly
states the crux of this discussion: An apparent need to control user
behavior.
Jakob Nielsen's Alertbox at http://www.useit.com/alertbox/20040913.html
discusses the need for standards. One of my favorite quotes of his is:
"Unfortunately, much of the Web is like an anthill built by ants on LSD:
many sites don't fit into the big picture, and are too difficult to use
because they deviate from expected norms."
Another thing I try to remember is Jakob's Law of the Internet User
Experience: users spend most of their time on other websites.
It's on those other websites that users determine their expectations.
This can turn sour if we're not careful about what we do. At
http://www.useit.com/alertbox/991114.html, Nielsen discusses when bad
design can become the expected standard.
We all know it's fairly common for usability guidelines to conflict. For
example, in 2005 Nielsen altered his 1999 usability guideline about not
opening new browser windows. His Alertbox at
http://www.useit.com/alertbox/open_new_windows.html discusses support
for opening new windows for non-PC formats including PDFs.
Accomplishing his suggested method gets more complex than most will have
patience for. And we must consider that the studies were done with
intranets.
Even though we continue to hijack users' browsers by opening files in
new windows (it wasn't my decision to make), we have designed an
accessible method that alerts all users to file size, file type, and
off-site links regardless of device and capability.
We style the information to be visually different than the link text and
then include it in the link. This method provides all users with a scent
of what they need to know to make their own decisions--except for the
fact that we don't include information in links to files about opening
them in a new window.
I'm also not a fan of icons.
You can see how it works on the following pages:
http://www.lni.wa.gov/ClaimsIns/Insurance/Learn/StateFund/RelatedInfo/De
fault.asp
http://www.lni.wa.gov/ClaimsIns/Insurance/Learn/StateFund/Reports/Defaul
t.asp
From: Simius Puer
Date: Thu, Aug 06 2009 4:30AM
Subject: Re: Title attributes on images and links
← Previous message | Next message →
>
> > Just as <bold> and <i> were depreciated because they were "style"
> > not "structure
>
> Yes, but opening a link is behavior, not style or structure, so it's
> totally
> irrelevant to the discussion.
...agreed, if you take what I said out of context and ignore the rest of the
sentence the point is irrelevant. The thing is it was part of the whole W3C
movement towards getting developers to stop using code
inappropriately...such as the examples given, and using tables for layout
etc etc
> > the target= was depreciated because you should
> > *not*interfere with the users browser...if they want to open it in a
> > new link they can!
>
> Problem is that most people have no clue as to how to do this.
...a fair point but a subjective one without statistics to back it up.
Sadly without any evidence I'd have to say you could possibly be right, but
have you considered why that might be?
The problem lies in the years of inconsistently in how developers have
approached this issue and Lon referred to this perfectly referring to
Neilsen's comments on "when bad design can become the expected standard".
Look at it another way: should developers go back to the old habit of
"designing for IE", or maybe we should bring back tables for layout? These
practices took years to be accepted as wrong (and sadly some people still
follow them) as so many developers took the easy route. Its easy to argue
this case is different, but I'm sure anyone who supported any of the old bad
practices would have said the same thing.
Could I also bring the focus (no pun intended) back to the fact that this is
a forum for *accessibility*. Putting aside the commercial/general best
practice debate for a moment - opening new windows is *not *considered fully
accessible. See WCAG guideline
3.2<http://www.w3.org/TR/WCAG20/#consistent-behavior>in general and
3.2.5 specifically and the section on "changes in context".
> as for 'forcing' developers to use JavaScript...finding away around a
> > restriction that is there for good reason is the developers fault and was
> > not the intention of the W3C.
>
> That is your opinion, not fact. And I heartily disagree.
...do you mean to say you believe this was the intention of the W3C? Whilst
you could argue that what I said is 'opinion' - I think it is exceptionally
safe to assume that the W3C don't dream up barriers for developers just to
see how they will get around them.
Incidentally, target="_blank" was depreciated in the Strict doctypes *only*.
If opening new windows is a considered a required behavior for your website
then you simply need to use a Transitional doctype. There is absolutely no
need to find a "hack" simply to get your site to validate. In fact it could
be argued that whilst you might be getting "valid" code it is not "correct"
code in the 'spirit' of the doctype you have chosen.
The same goes for WCAG 2.0 compliance where guideline 3.2.5 (Changes of
context <http://www.w3.org/TR/WCAG20/#context-changedef> are initiated only
by user request or a mechanism
<http://www.w3.org/TR/WCAG20/#mechanismdef>is available to turn off
such changes) is only required for level AAA.
> because you should *not*interfere with the users browser...if they
> > want to open it in a new link they can!
>
> This is a reasonable argument for making "target='_blank'"
> non-conforming, although I don't entirely buy it.
>
> But do you have a citation that shows this was the /actual/ reason why
> HTML4 made "target='_blank'" non-conforming in Strict HTML, or are you
> just putting forward a rationalization of the decision? I've never found
> a record of the reasoning behind it
>
Sorry Benjamin I can't give you a hard citation ref to check for that
against. I used to have the luxury of being having enough time to be
involved in various W3C discussion groups on as part of a previous job.
The exact reason given for dropping the support for target="_blank" was that
"it breaks the functionality of the back button". It only got applied to
the Strict doctypes as it was recognised that this would cause issues for
many webmasters in the short term.
There are records of most of the W3C discussions if I recall correctly...you
just need some (ok, a lot) patience to find what you are looking for.
From: Geof Collis
Date: Thu, Aug 06 2009 5:35AM
Subject: Re: Title attributes on images and links
← Previous message | No next message
>So what happens if someone has a pop up blocker turned on, will it
>not affect windows being opened in new windows?
I also find it problematic if the alert for opening a new window is
not part of the link name, especially if I am using my JAWS drop down menu
cheers
Geof
Editor
Accessibility News
www.accessibilitynews.ca
Accessibility News International
www.accessibilitynewsinternational.com