In the Web Content Accessibility Guidelines is states that you should supply a "skip" link that jumps you (for example) over a navigation block and straight into the content. This is particularly useful for impaired users who use a screen-reader to describe a page audibly.
6.2 Grouping and bypassing links WCAG Guidelines
However, this technique relies on using the name attribute on an anchor tag:
<h2><a name="content">Content</a></h2>
Along with the skip-to link:
Skip to content
The problem is, the "name" attribute of the anchor tag is obsolete in HTML5. HTML Obsolete Features
Is there any other way to achieve this "skip to" functionality without using the name attribute?
Footnote: The status of the HTML5 specification in still in draft and it is possible that the name attribute will actually continue to be allowed in this scenario - although it will probably still generate a "warning". It has currently been marked as "obsolete but conforming", which means you COULD still use it - however, I would like to know of other ways to perform the "skip to" to see if there is a way to do it that doesn't rely on an obsolete attribute.
Instead of using <a> tags, you can use any element with the id attribute:
<h2 id="content">Content</h2>
Skip to content
EDIT, found you a source (albeit it's Wikipedia ;-)):
Alternatively (and sometimes concurrently), with the name or id attributes set, the element becomes a target. A Uniform Resource Locator can link to this target via a fragment identifier. Any element can now be made into an anchor by using the id attribute,[2] so using <a name="foo"> is not necessary.
http://en.wikipedia.org/wiki/HTML_element#Anchor
Related
I see this a lot on site title links in WordPress themes (probably because Underscores does it and everyone copies that):
Some Site Title
I cannot find even a semi-authoritative statement anywhere that rel="home" on an anchor tag is used meaningfully today by any browser, screen reader, or other user agent. The only "official" documentation I've located is this draft specification from 2005 on the microformats.org site.
That doc proposes home as a valid value on both <link> tags in the <head>, as well as <a> tags. Using it on a <link> has some pedigree from HTML v3, and there's reference to it in the wild from 2002. But I haven't seen anything about the <a> tag usage.
So, is including it helpful for anything/anyone? Would I do better to use <link rel="home"> in the <head>, or is that obsolete too in 2020?
The rel="page" was part of an initiative to create permalinks (see section 'Permalink detection') as part of a standard in HTML 4.
However with HTML 5 it now has no purpose and does not offer any accessibility or SEO value. It also might not validate using W3C validator anymore (not tested).
rel="something" should only be used on <link> elements, with the exception of rel="noopener", rel="nofollow" or rel="noreferrer" on anchors (<a> tags).
Note - There may be other rel="" for hyperlinks but the two stated are the only ones I can think of, it is no longer valid to use it for page locations, bookmarks etc.
Update
Thanks to #Sean who pointed out in the comments other elements can accept rel="", however MicroFormats are not the preferred way of adding structured data according to Google and their development is not as full fledged as using https://schema.org and JSON+LD.
“We currently prefer JSON-LD markup. I think most of the new
structured data come out for JSON-LD first. So that’s
what we prefer.” - John Mueller
I am obviously incorrect in what I said as it is perfectly valid, however personally I would not bother and stick with what Google prefers apart from the few items I listed.
See #Sean's answer for a bit more info on the subject.
for clarity rel="" has no bearing on accessibility
home isn't one of the allowed keywords explicitly defined by the current HTML spec as allowed values for the rel attribute. However, the spec goes on to state that:
Types defined as extensions in the microformats wiki existing-rel-values page with the status "proposed" or "ratified" may be used with the rel attribute on link, a, and area elements in accordance to the "Effect on..." field.
On that microformats page, home has the "proposed" status—so it is valid to use according to the spec.
There's a specific rel-home page within that microformats site that goes into more detail about the usage with examples. It makes the statement—
Opera browser supports rel="home"
—which would imply that Opera has some functionality tied to that usage, but it doesn't provide any additional details.
Summary: rel="home" is valid to use on a elements. It's benefits aren't clear, but it doesn't hurt to use it. The draft spec for it has been around since 2005, so there's bound to be some technologies that make use of it.
I've been seeing these attributes around on more modern websites like GitHub and such, and they always seemed to coincide with a customized popover like the title attribute.
Option 1
Option 2
Option 3
Option 4
I read some documents about data- attributes on HTML5 Doctor, and I'm not quite sure of the point.
Is there some SEO or accessibility benefit to using them? And what is the plugin(hopefully jQuery) commonly being used to create the popovers in this specific case?
Simply, the specification for custom data attributes states that any attribute that starts with “data-” will be treated as a storage area for private data (private in the sense that the end user can’t see it – it doesn’t affect layout or presentation).
This allows you to write valid HTML markup (passing an HTML 5 validator) while, simultaneously, embedding data within your page. A quick example:
<li class="user" data-name="John Resig" data-city="Boston"
data-lang="js" data-food="Bacon">
<b>John says:</b> <span>Hello, how are you?</span>
</li>
From : Ejohn.org 'Not sure about the external link policy, just putting it in here in case someone wants to know'
HTML5 data-* attribute is used for storing data in element
For manipulating with this attribute you can use jQuery.data() or .data() methods.
The main point is that data- attributes will not clash with attributes that may added to HTML later or with browser-specific attributes. The idea is to give an author a playground, a name space where he can use attributes for private purposes without fear of having them ever interpreted as standard or vendor-defined attributes in some different meaning.
According to this idea, search engines and assistive software ignore such attributes, as they have no interoperable meaning.
I have been seeing the aria attribute all over while working with Angular Material. Can someone explain to me, what the aria prefix means? but most importantly what I'm trying to understand is the difference between aria-hidden and hidden attribute.
ARIA (Accessible Rich Internet Applications) defines a way to make Web content and Web applications more accessible to people with disabilities.
The hidden attribute is new in HTML5 and tells browsers not to display the element. The aria-hidden property tells screen-readers if they should ignore the element. Have a look at the w3 docs for more details:
https://www.w3.org/WAI/PF/aria/states_and_properties#aria-hidden
Using these standards can make it easier for disabled people to use the web.
A hidden attribute is a boolean attribute (True/False). When this attribute is used on an element, it removes all relevance to that element. When a user views the html page, elements with the hidden attribute should not be visible.
Example:
<p hidden>You can't see this</p>
Aria-hidden attributes indicate that the element and ALL of its descendants are still visible in the browser, but will be invisible to accessibility tools, such as screen readers.
Example:
<p aria-hidden="true">You can't see this</p>
Take a look at this. It should answer all your questions.
Note: ARIA stands for Accessible Rich Internet Applications
Sources: Paciello Group
Semantic Difference
According to HTML 5.2:
When specified on an element, [the hidden attribute] indicates that the element is not yet, or is no longer, directly relevant to the page’s current state, or that it is being used to declare content to be reused by other parts of the page as opposed to being directly accessed by the user.
Examples include a tab list where some panels are not exposed, or a log-in screen that goes away after a user logs in. I like to call these things “temporally relevant” i.e. they are relevant based on timing.
On the other hand, ARIA 1.1 says:
[The aria-hidden state] indicates whether an element is exposed to the accessibility API.
In other words, elements with aria-hidden="true" are removed from the accessibility tree, which most assistive technology honors, and elements with aria-hidden="false" will definitely be exposed to the tree. Elements without the aria-hidden attribute are in the "undefined (default)" state, which means user agents should expose it to the tree based on its rendering. E.g. a user agent may decide to remove it if its text color matches its background color.
Now let’s compare semantics. It’s appropriate to use hidden, but not aria-hidden, for an element that is not yet “temporally relevant”, but that might become relevant in the future (in which case you would use dynamic scripts to remove the hidden attribute). Conversely, it’s appropriate to use aria-hidden, but not hidden, on an element that is always relevant, but with which you don’t want to clutter the accessibility API; such elements might include “visual flair”, like icons and/or imagery that are not essential for the user to consume.
Effective Difference
The semantics have predictable effects in browsers/user agents. The reason I make a distinction is that user agent behavior is recommended, but not required by the specifications.
The hidden attribute should hide an element from all presentations, including printers and screen readers (assuming these devices honor the HTML specs). If you want to remove an element from the accessibility tree as well as visual media, hidden would do the trick. However, do not use hidden just because you want this effect. Ask yourself if hidden is semantically correct first (see above). If hidden is not semantically correct, but you still want to visually hide the element, you can use other techniques such as CSS.
Elements with aria-hidden="true" are not exposed to the accessibility tree, so for example, screen readers won’t announce them. This technique should be used carefully, as it will provide different experiences to different users: accessible user agents won’t announce/render them, but they are still rendered on visual agents. This can be a good thing when done correctly, but it has the potential to be abused.
Syntactic Difference
Lastly, there is a difference in syntax between the two attributes.
hidden is a boolean attribute, meaning if the attribute is present it is true—regardless of whatever value it might have—and if the attribute is absent it is false. For the true case, the best practice is to either use no value at all (<div hidden>...</div>), or the empty string value (<div hidden="">...</div>). I would not recommend hidden="true" because someone reading/updating your code might infer that hidden="false" would have the opposite effect, which is simply incorrect.
aria-hidden, by contrast, is an enumerated attribute, allowing one of a finite list of values. If the aria-hidden attribute is present, its value must be either "true" or "false". If you want the "undefined (default)" state, remove the attribute altogether.
Further reading:
https://github.com/chharvey/chharvey.github.io/wiki/Hidden-Content
setting aria-hidden to false and toggling it on element.show() worked for me.
e.g
<span aria-hidden="true">aria text</span>
$(span).attr('aria-hidden', 'false');
$(span).show();
and when hiding back
$(span).attr('aria-hidden', 'true');
$(span).hide();
Reading google prompt for using alt in internal links (https://support.google.com/webmasters/answer/47334) I looked for answers. I found a bit old thread (Is it correct to use alt tag for an anchor link?) in stackoverflow with reasonable answers that using alt for an anchor link is incorrect.
Can someone help me understand better?
The answer provided by Google is a little confusing. The alt attribute (according to the specification anyway) is not a valid attribute of an a tag. The only valid attributes for a elements are as follows:
charset
type
name
href
hreflang
rel
rev
accesskey
shape
coords
tabindex
onfocus
onblur
What the answer really means is as follows:
For example, for your site's internal links, make sure you use anchor
text and alt text for images that's informative, compact, and
avoids repetition.
You should use the title attribute for anchor tags if you wish to apply descriptive information similarly as you would for an alt attribute. The title attribute is valid on anchor tags and is serves no other purpose than providing information about the linked page.
W3C recommends that the value of the title attribute should match the value of the title of the linked document but it's not mandatory.
http://www.w3.org/MarkUp/1995-archive/Elements/A.html
Alternatively, and likely to be more beneficial, you can use the ARIA accessibility attribute aria-label (not to be confused with aria-labeledby). aria-label serves the same function as the alt attribute does for images but for non-image elements and includes some measure of optimization since your optimizing for screen readers.
http://www.w3.org/WAI/GL/wiki/Using_aria-label_to_provide_labels_for_objects
If you want to describe an anchor tag though, it's usually appropriate to use the rel or rev tag but your limited to specific values, they should not be used for human readable descriptions.
Rel serves to describe the relationship of the linked page to the current page. (e.g. if the linked page is next in a logical series it would be rel=next)
The rev attribute is essentially the reverse relationship of the rel attribute. Rev describes the relationship of the current page to the linked page.
You can find a list of valid values here: http://microformats.org/wiki/existing-rel-values
As I explained in the linked question, the a element can’t have an alt attribute.
Google’s documentation is not really formulated with sufficient precision:
For example, for your site's internal links, make sure you use anchor text and alt text that's informative, compact, and avoids repetition.
While it might be the case that they think of images being part of the anchor text (they should say so!), it could also be the case that they confused alt with title (which is an error you’ll often find, for example in this question).
I have read on Mozilla website regarding the title attribute : "contains a text representing advisory information related to the element it belongs to".
But also, in the first paragraph of the page regarding all global attributes (title included): "HTML defines a few attributes that are common to all HTML elements. These attributes can be used on all elements, though the attributes may have no effect on some elements"
Is it anywhere specified (source please) on which element the title attribute has "no effect"?
I curious why this seems so vague, maybe I simply missed something.
I created a jsfiddle where title attribute seems to "have an effect" (on Chrome, FF29, IE11) on tags: <a>, <img>, <p>, <div>
It depends on HTML version where the title attribute is valid. Originally, it was allowed for links (a elements) only and was meant to help the user see, on mouseover, some information about the linked resource, useful for deciding whether to follow the link or not. This might still be regarded as the most useful way of using title.
Later, the attribute was allowed for most elements, and HTML5 proposes to remove all restrictions, mainly just for simplicity. The formulation about the effects is intentionally vague, since the effects are expected to be browser-dependent, and they often are. For example, speech-based browsers may optionally speak the title attribute value when encountering an element that has it; but this can usually be switched off.
For example, in HTML5, the title attribute is also allowed for a head element, but it normally has no effect there, since that has no content to be rendered (as part of the document).
The title attribute is mostly used to show users information (“tooltip”) on mouseover. This is in many ways problematic, due to the primitive and uncontrollable user interface and other problems. Therefore, people often use other techniques, such as “CSS tooltips”, instead. But for compatibility with past specifications and practices, title attributes are kept as part of the language. It is unlikely that its meaning will be specified more exactly.