A Link must have appropriate text description
A link must have a text-based name related with it so that screen readers can announce something to users.
Good Example: Link text within the <a> element
Link text must have clear concept for the screen reader users, must not have a duplicate label, and must be focusable. Using the proper HTML element for links, the <a> will ensure that every link has an accessible name.
Begin code:
<p>
<a href=”https://beyondourvision.com”>Web Accessibility Services- Beyond Our Vision </a>
</p>
End code.
If a link has image then web developers must use “alt attributes with ankor tag.
Good versus Bad Link Text
Avoid using text like,
Read more
Click Here
Good Example: Link text makes sense out of context
Here are few examples,
Begin code:
<p>
Learn more about
<a href=”/coronavirus.html”>Corona Virus Report In Pakistan</a>
</p>
<p>
Read an awesome article about,
<a href=”http://www.factretriever.com”> Crazy facts about lion life </p>
End code.
Bad Example: Non-Descriptive Link Text
The links shown do not convey the purpose of the link within the link text, making it more difficult for screen reader users to understand where the link goes if they listen to a list of the links out of their context on the page.
Begin code:
<p>
Learn more about our products
<a href=”/products.html”>here</a>.</p>
<p>To read a fascinating article about the resident microbes in the human body
<a href=http://www.beyondourvision.com> click here</a>
tinyurl.com/c3z77jt”>click here</a>. </p>
End code.
The link text SHOULD NOT repeat the role (“link”).
Screen readers will say “link” and then read the link text, so there is no need to add the word “link” in the link text.
Bad Example: Links to the Same Page with Different Link Text
These two links go to the same location but have different link text.
Begin code:
<p><a href=”contact.html”>Our Company</a></p>
<p><a href=”contact.html”>Contact Us</a></p>
End code.
Bad Example: Links to Different Pages with the Same Link Text
These two links go to different locations but have the same link text.
Begin code:
<p><a href=”contact.html”></a>Contact Us</a></p>
<p><a href=”directory.html”>Contact Us</a></p>
Links to External Sites, New Windows, Files
A link that opens in a new window SHOULD point out that it opens in a new window or tab.
It can be useful to users to know when a link will open a new window. With a text indication (e.g. “opens in a new window”) or an icon with same alt text are two of the most common methods to point out this. Make sure the recommendation is available to both sighted users and blind screen reader users.
Bad Example: No indication that the link opens in a new window or tab
The link doesn’t give any warning that it will open in a new window.
Begin code:
<p>
<a href=http://www.beyondourvision.com/ target=”_blank”> Web Accessibility Services-Beyond Our Vision </a>
</p>
End code.
A link to an external site MAY indicate that it leads to an external site.
It can be helpful to users to know when a link will take them away from the current web site to a different web site. Adding a text warning (e.g. “link leads to an external site”) or an icon with equivalent alt text is two of the most common ways to indicate this. Ensure the indication is available to both sighted users and blind screen reader users.
Good Example: Text warning that the link goes to an external site
The link in this example includes a text note at the end of the link showing that it leads to an external site.
Begin code:
<p><a href=”http://www.google.com/”>Google (link leads to external site)</a></p>
End code.
Bad Example: No indication that the link goes to an external site
Although the link leads to an external site, there is no clear indication that it does.
Begin code:
<p><a href=”http://www.google.com/”>Google</a></p>
End code.
Visually Different from Text
Links MUST be visually distinguishable from surrounding text.
Sighted users can easily differentiate in between link text that is within a paragraph or other block of text and surrounding text. If they can’t tell the difference, they won’t know what items are clickable, and they may miss important links. There is no need to change the default styling to get accessibility be standards.
There are a few common ways to distinguish between links and text:
- Different color plus underline: This is the default styling in browsers.
- Different color plus underline the links only on hover and focus: Some designers don’t like the look of underlined links, so they remove the underline from the styling. Removing the underline is not recommended for links in the main content area of a document, because people with low vision may not be able to distinguish the color of the text from the color of the links before hovering over them with a mouse or tabbing to them with a keyboard. Still, this technique can be allowable (though discouraged) if there is a contrast ratio of at least 3:1 between linked text and non-linked text, and as long as the underline becomes visible on keyboard focus (when users tab to the link) as well as on hover (when users place the mouse over the link).
- Different background color on hover and focus: This technique can be used in combination with adding an underline on
Links and buttons SHOULD be selected semantically according to their functions.
Here are the main basic factors between links and buttons:
- Links take users to different locations (either to a different page or to a different location on the same page);
- Buttons start scripted functionality (e.g. make a dialog appear, expand a collapsed menu, turn font bold, etc.), usually on the same page, but a button can also submit form data.
Sometimes it is difficult to understand, whether a control should be a link or a button, but in most cases the difference is clear.
Screen reader users are informed whether something is a button or a link
Screen readers always say “link” before links, and “button” before buttons, so screen reader users always know which is which, at least in terms of the markup. Web developers sometimes take the difference lightly, sometimes giving links button-like scripted functionality, and sometimes making buttons take users to destinations as links normally would. The problem with this wrong thinking is that when a screen reader user wants to find a link, the user may pull up the list of links and not find the link anywhere because it turns out that it has actually been selected as a button in the markup, or vice versa. This kind of button and link confusion can be frustrating for screen reader users.
