This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
Is putting a div inside an anchor ever correct?
I want to have a link on a complex element (containig images, paragraphs and other stuff).
I know it works, but is it ok to have a <div> element inside an <a> element ?
Yes … and no.
No complete HTML or XHTML recommendation allows it.
The HTML 5 draft does permit it, but you may have to do things such as explicitly setting display: block on the anchor to get it to work in some browsers. You may find that others simply don't support it (I'd like to be able to link to a reference that shows browser support for this, but don't know of one, please comment if you do.)
That said, while have nice big click targets can be useful, it isn't an approach that is friendly to the "skim through links mode" that some browsers (especially screen readers) have. You might be better off using a regular link in the content, and applying some JavaScript to react to a click on the whole element.
In XHTML1.0 and HTML4.01: no. a is an inline element that can only contain other inline elements (but not another a).
In HTML5: yes, you are allowed to do that. BUT consider why you would've hundreds of characters in a link.
It's bad for SEO (dilution I believe) and bad for many disabled users ("Hey screen reader, tell me what does this link do?" - "Let me read to you aloud this link for half a minute") and perhaps bad for usability.
Another solution would be to put a link on say your heading in your div or some meaningful text. Then in JS make your div behave like what you wanted to do initially. Then it'll work for users using an assitive technology (screen readers and alike), for keyboard users (they can tab through the link) AND for sighted mouse users with JS.
No, unless you don't care about IE7 and down. The link will not function properly in IE7, even if set to display:block.
Related
I am using a html5 header element to display a logo inside the body. ANDI accessibiility compatibility is recognizing this as a landmark. I tried going thru the documentations but they only specifiy how to add landmark but do not mention how to ignore or remove an unwanted landmark.
How do I make header/any element in future a non landmark. Any attributes I could set or any directions would be helpful.
Note: I'd still like to be able to use header element.
If useful, its an angular application. Thanks in advance.
Don't use a <header> element.
It isn't about what you want it is about what people need in order to access your site correctly.
Semantics are really important for accessibility, especially for screen reader users and trying to rely on aria to override an elements semantic role is a bad idea.
Screen reader users navigate by landmarks and expect to see them in certain places, this is one of the main reasons it is important.
There is nothing wrong with using <divs> for things that do not form part of the document structure.
If you want to know what to use instead please add a fiddle / link to your question, just in case there is a more appropriate element with the correct semantics.
So if I need to do it for legitimate reasons.
Use role="presentation" as this converts an element to be treated like a <div> (which has no semantic role.). However as stated this should be used sparingly support for aria is not as good as you might think..
HTML5 allows for links to be wrapped around block elements (one or several), but how exactly will it render in older browsers? Let's say to go as far back as IE6.
I haven't found full details yet (but there are some examples).
The markup would be as follows:
<a href="http://example.com">
<section>
<h3>Heading</h3>
<p>Text</p>
</section>
</a>
Also, would the most semantic way to make it compatible in older browsers be to wrap the links inside each block element separately? I've seen suggestions to replace the block elements with span, but that'd make it inline and alter the meaning of headings.
I've noticed that even modern browsers (e.g. Safari on iOS 6) do weird things. For example, try clicking on the image in this JSFiddle from your mobile brwoser — even though it shares the link with the caption below, the caption doesn't get highlighted for me. Furthermore, when clicking the caption, the image nor caption get highlighted.
As far as I know, the behavior is generally the same as modern browsers. Everything in the sample markup given will turn into a single hyperlink. This is regardless of whether or not you include the HTML5 shiv for older IEs to recognize the new semantic elements.
This is probably because there's nothing in HTML that says a specific starting tag should automatically close an unclosed <a> tag — the end tag is required to denote the end of a hyperlink.
And yes, that's how I'd do it to preserve semantics if I want to conform to an older HTML doctype. It's not required for HTML5 conformance though, since it works based on the assumption that even older browsers already behave this way (backward compatibility and everything).
Relaxing the content model for a in HTML5 is based on observations on actual browser behavior: the original syntactic requirements were not really enforced. This can be expected to go as far as you can get. (I tested this on IE 6 and Firefox 3.)
So there is no need for compatibility. But it would surely not be “semantic” to split a link element. Two links are semantically different from one link, for any reasonable semantics for “semantic”. It would also be a usability problem, especially when using the keyboard to move between links.
The visual rendering is a different issue. It is not clear at all, from the HTML5 drafts or from practical considerations, how a link should be rendered, in its different states, when it may contain just about anything. This may have been a key reason behind the old syntactic requirement. Browsers do not render such links consistently. This applies at least to underlining. There can be functional differences, too; e.g., on some browsers, the area on the right of the heading text is not clickable, i.e. only the text is “active”, whereas other browsers make the entire area of the element (which is by default the entire available width for a heading) “active”.
So the basic issue, if you wish to use such a link, is to consider how you intend to have it rendered and how to do that in CSS in a manner that works reasonably cross-browser.
I have built a custom context menu but have found annoyingly that when I right click on my site in firefox text and images just seem to randomly get selected.
The link below is a basic html dump of the page that is having issues. You can see that when you right click it in Firefox, certain elements are highlighted. Very annoying! This must be a purely html markup problem in Firefox as there is absolutely no CSS or JS on this page.
Example Here:
http://pastehtml.com/view/1e16jup.html
Love to hear your thoughts/suggestions...
There are a lot of errors in this page have a look at the validator result here.
Maybe it gives firefox a lot of problem rendering the page properly.
Close all the <meta> and <img> tags, <script> must have proper type attributes, tags like <h1> shouldn't be placed inside of <a>, <p> neither.
I'm assuming you mean the HTML5 contextMenu? Because this is not implented in any browser.
A bit of quick investigation seems to demonstrate that the header+footer elements have this behaviour. Also, lists appear to have it as well. This is because those elements have a certain semantic use and this behaviour seems consistent with those semantic uses. Check out the specification to see how these elements are intended to be used.
I'm firing blind but I'd suspect you can override this with -moz-user-select - but this is going contrary to the Firefox user experience. I wouldn't recommend it at all.
We have some code that removes "dangerous" attributes and tags from HTML. I noticed that style is among the list of "dangerous" attributes. What could be the risk from that attribute?
In IE you can include #behaviors in there which can load little Javascripts.
With CSS3 you can also interject little bits of text, which could be dangerous depending on your website.
Here's an example of a bug in MediaWiki that creates a vulnerability based on inline style attributes.
It's possible to make things that are invisible or otherwise very deceptive using style sheets. For example, you could put a giant, invisible anchor link over the whole page so that when the user clicks on something, he's taken to an identical page on a server in Russia.
I have a website in which I provide tool-tips for certain things using a hidden <span> tag and JavaScript to track various mouse events. It works excellently. This site somewhat caters towards people with vision issues, so I try to make things degrade as well as possible if there is no JavaScript or CSS and generally I would say that it is successful in this regard.
So my question is, is it possible for these <span> to only exist if CSS is being used? I have thought about writing out the tool-tips in JavaScript on document load. But I was wondering if there is a better solution.
Perhaps you need to re-think the way you are providing tooltips. Could the content be contained in the title attribute of a semantically appropriate element?
EDIT: If you provide more info, someone might be able to suggest more of a solution. What sorts of elements are the tooltips popping up on? Images? Would the abbreviation tags be appropriate?
Quick Solution I just came up with: <span> has access to the core attributes, which include title, so you could include the tooltip text in the title, and use a javascript library like jQuery to display tooltips for all spans with a title.
A quick hack would be to color the text the same as the background (say, white on white) in html, and then use CSS to change the color back to something visible (black on white). Of course, this is only relevant for people able to see the text. Screen readers and such wouldn't see the text as hidden.
CSS is also used by screenreaders to help define which page elements are read or not.
Screen readers will almost always ignore elements with display:none applied to them, so not using CSS is not a valid indicator of a screenreader's presence.
I would go with Chris' idea of using javascript to generate the tooltips based on a title (or alt) attribute.
You could use JS to ensure that tooltips are only displayed when valid styles are set, so if JS is enabled and CSS disabled you can treat the extra information differently (eg footnotes).
http://juicystudio.com/article/screen-readers-display-none.php
http://www.456bereastreet.com/archive/200711/screen_readers_sometimes_ignore_displaynone/